<daviid>guile-lib os/process does ... (setvbuf (cdr result) _IONBF) which should become (setvbuf (cdr result) 'none) for guile-2.2 what is the recommended way to patch this? I was thinking of a cond-expand, but in the 2.1.4 doc I dont tsee any guile-2.2 <daviid>ot does guile-2.o also accept (setvbuf ... 'none) as well maybe? <daviid>indeed we have a guile-2.2 feature, not documented though ***holomorp1 is now known as holomorph
***karswell` is now known as karswell
<marusich>Just discovered C-c <. Can't believe I didn't know about this. Goodbye, grep! <amz3>catonano: héllo, did you manage to get the database working? <amz3>catonano: was my last my helpful? <catonano>I managed to correctly insert packages nodes and correctly fetch them <catonano>Now I'm mumbling ow to cicle through to insert edges too <amz3>ah no it's not about that <amz3>I was just asking like that <amz3>also I am curious what you will come up with <catonano>the only note is "get-or-create-context" was undefined and in order to test I didn't bother to see in which moduleit's defined <catonano>if anything meaningful comes up, I'll post on the guix mailing list. Because the aim is packages management, after all <amz3>it's defined in wiredtigerz but it's not public, yet. <void-pointer>Was looking at R7RS and decided to look at where Guile was on it and noticed there was a branch in the git repo for adding R7RS features and libraries, though it hasn't been touched in 2 years. I am a bit curious as to what the situation with that is. It isn't quite complete (missing documentation for one), so I suspect that is why it has not been incorporated. <void-pointer>Or is that something that is planned for Guile 2.4 instead of 2.2? <ArneBab_>(these are benchmarks, so this does not imply that Guile is completely r7rs compatible, just that the benchmarks work) <void-pointer>That page was part of what got me to read the whole R7RS-small standard and then to look at where guile is at <void-pointer>Many of the parts are there, just not organized into the R7RS-small library scheme <void-pointer>Big things missing are R7RS-small's library syntax and its include procedures/macros/directives <ArneBab_>ah, ok - sorry for repeating what you already knew :) <void-pointer>ArneBab_: it is ok. You didn't know that, so you gave some information. Also, it is an interesting read for anyone else here in this channel who doesn't know about it. So it was a good thing that you brought that up <void-pointer>Yes, though 2.1.4 probably has a bit more coverage than 2.0.12 <ecraven>void-pointer: I'll try to get 2.1.4 into the charts next week <ecraven>well, some of the work is trivial.. boolean=? for example isn't that complicated to support :) <ecraven>but of course, not that interesting either <ecraven>the master plan is to get all r7rs modules in there, some day <ecraven>so not just r7rs-small, but r7rs-large <ArneBab_>void-pointer: and it prompted ecraven for additional info :) <ijp>my own view is guile should pull a racket, and we should stop pretending scheme is a thing <void-pointer>ijp: I can see a few benefits to a new language, but the downside is going from having code portability be in the low to high range (depending on which features are used) to the zero range <void-pointer>scheme does have a few deficiencies for getting things done <void-pointer>though scheme has improved considerably, even if one ignores R6RS (really looking forward to R7RS-large since R7RS-small was quite good) <void-pointer>It is interesting how many schemes have implemented similar extensions <ecraven>void-pointer: r7rs-large aims to rectify that, by defining tons of libraries :) <ArneBab_>ecraven: is there a column for guile 2.1.4 on another version of the stats page? <ecraven>I haven't run the tests on guile 2.1.4 yet.. should be simple to add, all you need is in that repo <void-pointer>I rather like the approache R7RS has done so far. I would only do one thing differently. <void-pointer>If an implementation has some of the libraries (but it need not have all) in R7RS-small, then it is R7RS-small <void-pointer>And then split what will be in R7RS-large into two rings, one a more core set of libraries and then the more extendended <void-pointer>Implementing all of small but some of the first ring would then be R7RS-medium. Implementing all of medium and some of the rest would be R7RS-large <void-pointer>And then implementing the whole thing would be R7RS-full <void-pointer>Which is what small and large will do (unless large adds more to the core) <void-pointer>Just think there should be more rings so that implementations have more precise language for what they are aiming for and people don't unfairly compare them <void-pointer>Unfair to compare something aiming at micro with something aiming at full <ecraven>well, there are certainly things that should not be in r7rs-small, and others that should be, but aren't.. but r7rs *seems* to be more of a consensus than r6rs ever was <void-pointer>I think to some degree, R6RS turned heads away for that alone <amz3>FWIW I prefer to stay a scheme <void-pointer>since it means much more portability between R6RS implementations than between R7RS <void-pointer>I personally wouldn't mind seeing Guile implement a few more lisps in addition to scheme <ecraven>void-pointer: I don't quite see the point of that :) but everyone can implement whatever s/he wants, so that's fine <void-pointer>but could see other languages be separate packages that build onto it <amz3>something like guile-log? <df_>ACTION would love cl-on-guile <amz3>what's up with common lisp? <ArneBab_>ijp: I like having Guile as a Scheme - if it hadn’t been a scheme, I’d never have started using it. <void-pointer>Though if Guile had been common lisp, I would have been pulled to it if I had gone down the common lisp path (or if I would in the future) <ecraven>r7rs-large should be at least as comprehensive as CL, I guess? <ArneBab_>ijp: that doesn’t mean that Guile has to restrict itself to providing only r7rs-large <ArneBab_>ijp: I would love to see Guile use more of its unique features for its basics (like generic accessors and such) <df_>if I was only interested in scheme I'd probably favour something like chicken <df_>it's a nice implementation with a lot of third-party libraries available <df_>also historically it beat guile on performance - that's probably no longer true, especially vs 2.2 <void-pointer>As it stands, there are a handful of libraries in guix and the rest one has to do manually <void-pointer>Well, chicken when compiled still beats Guile 2.2 in a lot of things, but loses in more than a few. The benchmarks showed them to not be that far apart <void-pointer>in those benchmarks, it performed the worst out of all of them <df_>void-pointer: well that's ok really because you can just compile for production use <df_>but guile 2.2 at least parallels it and I forsee it getting better <amz3>yes, there is a lot of eggs... just a few checks indeed there is a lot... but it's not because it's online that it works... <amz3>also, it's easy to create guix package for pure guile package <amz3>even if it's a lot more friction that what is done with eggs <df_>guix is a major reason that guile is my scheme of choice :) <amz3>because it's innovative? <void-pointer>Downside of Guix is that Guix is a package manager for everything in addition to Guile scheme libraries <df_>yes, people are doing cool stuff with guile <amz3>void-pointer: that's an upside actually <void-pointer>It is a rather big kitchen sink to install just to get Guile library management <df_>void-pointer: is that a downside? I want a package manager, and not all software is written is scheme <void-pointer>Also, what about being on a system guix doesn't support but guile does <df_>personally I think guix looks like a better kitchen sink than any of the others out there <amz3>yeah, some time it's gets in the way, I just had to create a package for Link-Grammar because guile could not find some of its dependency in /gnu/store/... <void-pointer>Guile, for example, should work on [some obscure processor], but it could be a lot of work to get guix on it <amz3>or some other reasons, but getting LG into guix made my bindings work <void-pointer>Also, not sure how well guix runs for non GNU/Linux folks <void-pointer>But, the nice thing is that it is written to be quite generic and it's way of allowing different users to use different packages is very very very powerful <df_>well the guix bootstrap binaries are likely to be available for any system that can run gnu stuff, aiui <df_>as for the linux side of things... well, there is an experimental hurd port <df_>I'd quite like to see things like guixsd gnu/kfreebsd or illumos <void-pointer>The other day, I was thinking about a particular project I would like to do in a lisp and have it be very cross platform, so this has been on my mind <void-pointer>Conclusion was to either go Scheme with Racket or Chicken (or possibly a few others), or go Common Lisp on say SBCL or ECL <void-pointer>Mainly due to not knowing how well Guile currently runs on Windows (may run well, in which case it is in the hat) <void-pointer>And frankly, I don't like having to support the OS for my stuff, but it is what everyone else demands <df_>hmm... I have no idea about windows, but I would guess that racket would be the best bet there <df_>in the CL world, maybe clozure <df_>otoh it supports a fairly limited set of cpu archs <amz3>sorry, but I don't care about windows, call me egocentric <df_>amz3: I don't care either, but sometimes there are legitimate reasons to support it imo <void-pointer>At least they are running XP or 7, so they aren't as terrible as they could be <void-pointer>Turns out Windows was sort of the key to figure out a bug I had in one of my python packages. It worked, despite the fact it shouldn't, on most GNU/Linux systems <amz3>I never use windows anymore, it's been more than 10 years <void-pointer>And its Windows support has supposedly caught up finally <df_>well this is a good reason to try to make software as portable as possible <df_>back in the day I made sure a program I wrote worked on solaris and irix because I happened to have access to both (at uni) even though I used neither personally <df_>and this is why I want to see people focussing on free kernels other than linux <df_>didn't really like the UI (heavily mouse-based) <df_>but then I don't like this idea that an OS is everything from the kernel to the UI anyway <df_>stumpwm doesn't care what kernel it's running on <C-Keen>you can run plan9 without the window management stuff, cpu servers are just that <df_>ok, but can you run alternative window management stuff? <C-Keen>you can even replace it with your own window manager <C-Keen>or run just one application like acme, the emacs of plan9 <void-pointer>especially changing its programming while it was running <df_>more unixy kernels are an easier place to start though <C-Keen>the most likely show stopper is that plan9 is not at all POSIX like so everything that relies on that will be a pain or impossible to get working <C-Keen>fortunately chibi works there, so there's a modern scheme... <df_>well the solution is obvious, posix needs to be replaced with nice modern scheme-based interfaces <void-pointer>Any move to do that will devolve into a flame war over it being scheme <ArneBab_>df_: I decided on Guile, because it is a Scheme, it is roughly as active as other Schemes and it is the extension language of the GNU project. <void-pointer>and knowing luck, it would probably be brainfuck that wins out <ArneBab_>void-pointer: sorry that I did not yet get forward with guildhall - I’m held up by having to provide a secure web server… <df_>void-pointer: but guile supports ecmascript! (ish) <df_>ArneBab_: the third reason was my main one <void-pointer>I looked at PyPI and saw such a thing is an absolutely huge undertaking <df_>lisp machines supported multiple lisp dialects and interoperability between them, I believe <amz3>«void-pointer | and knowing luck, it would probably be brainfuck that wins out» x) <df_>so it is totally possible to keep all the dynamic language people happy <df_>it's just unfortunate that right now we're all using C-machines <ecraven>df_: but the difference between those lisps was less than the difference between Scheme and CL <ecraven>also, the symbolics lisp machines did support at least fortran and C, maybe even cobol <void-pointer>if i understand it correctly, they weren't running lisp directly, just had a lot of CPU instructions that were tuned to running lisps to make the VM easier and better performing <ecraven>void-pointer: what is "run lisp directly"? <void-pointer>Just, it had instructions that made lisp environments run a lot lot faster <df_>ecraven: but CL and scheme are not so different that one could have an operating environment that supports both, right? <ecraven>well, I know of no cpu that is a compiler <void-pointer>Probably also had some hardware support for garbage collection <df_>I mean look at the variety of languages on the jvm <ecraven>and there are good reasons not to run interpreters directly in hardware <ecraven>df_: I'm not sure... I "symbol" in CL is something *totally* different than in SCheme <df_>lisp machines supported various lisp features in hardware - tagged types spring to mind <ecraven>and as far as I know it was something kind of similar in Zetalisp, Symbolics-CL, Future-CL etc. <ijp>void-pointer: there is no "new language" here. it's just making the status quo official <ijp>and code portability is essentially nil in scheme to begin with <df_>ecraven: still, compatibility between dynamic languages (not just scheme and CL) seems a lot easier than the mess of having to talk to C via ffi <ijp>and flexibility in the standard, which you cite as a positive for r7rs over r6rs, is antiportability by definition <void-pointer>ijp: ah, I see. That is what you meant. Basically, no longer even promising to try to stay portable <ijp>ArneBab_: which are also mostly unportable <ecraven>df_: well, there are a few very nice ffis, I'm not sure that's such a hard problem.. (for C, C++ is something different entirely :) <df_>but do you think it's a harder problem to solve the impedance mismatch between (say) scheme and C, and scheme and ecmascript? <void-pointer>ijp: the flexibility does hurt portability some, though, it does get things more on one page and it makes things better than C programming (number of issues that have to be handled by cond-expand way less than those with C header files) <void-pointer>getting people on the same page is also a means to an end on portability <ecraven>df_: I don't see that much of an impedance mismatch between Scheme and C <ecraven>sure, you need to handle malloc/free, but that's simple in Scheme (for interfacing to C) <ijp>although the issues, minus gc, are pretty much the same <void-pointer>So getting C++ to work with other things doesn't work so well unless functions were declared with extern "C" <ecraven>and you need a GC that can keep things at fixed adresses, if you've given them to C <df_>basically I guess my problem is that at the moment, the lowest-common-denominator for any popular OS is C <ecraven>void-pointer: look at clasp (a c++ CL) <ijp>ecraven: and you need to prevent C programmers from freeing scheme things they shouldn't <ijp>and you need to deal with continuations <ecraven>ijp: yea, I was assuming you only use C as "library calls" <ijp>and you need to deal with calls in and out of scheme and the attendant tail recursion <void-pointer>And you need pointers to some extent in scheme or whatever language is chosen <df_>I'd like to see that change to some kind of higher-level thing like tree-il <ecraven>ijp: hm.. I never thought about how continuations interact with ffi code <ijp>in guile it will usually error <df_>(ok tree-il probably isn't low-level enough, but the general idea is to have something that can support plenty of dynamic language paradigms without having to get too close to the ugly hardware) <ecraven>df_: hardware isn't ugly :) if you want things to get fast, you need to think about hardware <df_>isn't that compiler-writers' jobs? :p <ijp>programming and hardware design are likely to get closer together in the near future, in the glorious fpga future <df_>(although as mentioned, we could have hardware that isn't basically designed to be a C-machine) <ijp>s/in the near future,// <ecraven>df_: until compilers are decent AI, the way you write your high-level code will matter... <ecraven>(filter identity (map ...)) just isn't the same as (filter-map ...) in most compilers, I think? even though with decent stream fusion it should be :-/ <df_>ecraven: true, but we could approach this problem either by improving compilers or improving hardware <ecraven>df_: yes, hardware support for tagged pointers for example would be so awesome <void-pointer>I would just be happy to see separate stacks for instruction pointers (call push and return pop) and data (buffer overflow would still be bad, but not as bad, though if when doing a call one could tell the CPU limits on how much down the stack the called procedure is allowed to go till an error, it would be even better) <void-pointer>buffer overflow would be data corruption instead of return to the wrong place and start executing the wrong code <df_>it does seem quite crazy how many common exploits could be prevented by slightly tweaking the way hardware works <ijp>data corruption itself is problematic for security <df_>how about ascending stacks? <ArneBab_>ijp: I’m often used information from racket or chicken on some SRFI or on syntax-case to get a task done <ArneBab_>but with racket that’s sometimes problematic <ijp>this does not contradict what I said <ArneBab_>(some things are just slightly different) <ArneBab_>ijp: not the incompatibility of code, but it shows me that being a scheme is an advantage <ArneBab_>it would be great to be able to have certain source files as strict r7rs while using Guile features in others <ArneBab_>ijp: compatibility of documentation (to a large degree) already helps a lot <ArneBab_>and that’s another point SRFIs provide: shared documentation. <wingo>i would like for guile to implement more of racket, and vice versa <ijp>arnebab_: you are assuming that the srfis are shared to begin with, which is frequently not true <ijp>hell, there are even schemes that don't provide srfi 1 <ijp>and for those that are shared, their error behaviour certainly isn't <ijp>so you need to make sure you never run into an "error" which would be easier if it weren't the second most common word in every scheme document after 'list'