<mwette>chrislck: better place to look for example is system/base/pmatch.scm <rlb>terpri: fwiw, longest command on "abel" (arm porterbox) was unsurprisingly psyntax at just over 3 hours. <rlb>I think we'll probably just raise the global limit on arm* to say 200m on the debian buildds, but we'll see -- not my department :) <rlb>wingo: thanks wrt fluid-ref -- obviously I hadn't attempted it yet. <lloda>Scheme should be about doing the right thing, not about compromises. Having many implementations is a strength. If there's disagreement let everyone try and see what works best, not hurry things. Future code is more important than past code. ***ng0_ is now known as ng0
<wingo>lloda: what is that statement in reference to? <wingo>i agree but i compromise on things all the time :0 <lloda>the cond-expand exchange earlier <lloda>surely, things must work, I need a practical system too <civodul>that's without the (web client) changes, right? <civodul>the NEWS entries are nice, lots of new things again! <wingo>civodul: yes, feel free to land those changes if they work for you <civodul>i was waiting for feedback, though with intermittent email fetches :-) <wingo>civodul: i thought we talked over irc :) <wingo>civodul: do you think a pull-request kind of system would help guile? <civodul>wingo: it wouldn't help me :-), but i understand many people are used to that workflow <wingo>just thinking that it might be clearer sometimes when someone gives r+ <civodul>i guess the question is the extent to which an email-based workflow scares away potential contributors <wingo>like positive review, patch accepted, looks good to me, etc <civodul>in this case, it's perhaps a misunderstanding on my side: i viewed our discussion as just that, not as a formal "LGTM" <civodul>(also i just realized you had replied by email, which i hadn't seen, oops) <wingo>civodul: we still good for 3.0.0 on friday? <civodul>wingo: yes, i'll do my best to do some more testing by then <civodul>did lloda or anyone have patches that change the API somewhere? <civodul>i think you already merged some of that, right? <wingo>:) currently we're definitely slower tho :) <civodul>except on mbrot, we should do mbrot more often :-) <wingo>civodul: i looked through guile-devel and there is nothing i need to apply, going back to last august or so. there may be older patches tho as i am not up to date. similarly for bug-guile <wingo>ecraven: that is chez --optimization-level=2 fwiw :) <wingo>i.e. no unsafe optimizations <wingo>i think r7rs-large is more appropriate to an out-of-tree project <wingo>pretty sure there are two main things we would need to do to get closer to chez: generational GC and better compilation of things like "case" <wingo>register allocation would help also. <wingo>generational gc would be a big change tho :) <drakonis>by the way, last year's guile talk on fosdem included a line on the slides about getting closer to racket, how that one works? <wingo>slowly :) we do mixed definitions and expressions now, and the exceptions rebase goes in that direction <civodul>the social bit isn't quite happening yet, it seems ;-) <wingo>:) racket is also doing some pretty bold stuff right now with racket2 <wingo>anyway, guile 3 required a specific set of low-level skills; i think a lot of the rapprochement work can build on that without needing to go so deep into the compiler <lloda>civodul: my patches already got merged, thx :-) <civodul>after reading "we next explore the possibly of changing to an infix-oriented syntax", i checked the date of the post, just to be sure <civodul>apparently one can send such a message even if it's not April 1st <lloda>the syntax thing looks like a massive timewaster to me :-/ <wingo>still, it is not something that inspires me. to my eyes it is "software for other people", which i can only make so much of; I need to make things for myself :P <lloda>customers tend to be wayward <lloda>you show them one thing and they want another <wingo>but maybe matthew & co come out with something really compelling. i am glad that racket is willing to explore this space :) <civodul>yeah, let's watch it from a distance :-) <zig>this space (reader syntax) was explored several times in srfi process (sweet expression, wisp, ...) with barely any success afaik. <zig>my tiny experience with wisp, is that it is much more difficult to read that s-expr based on parens. <zig>racket is, willy nilly, into the idea of DSL with completly different syntax, that is why they have the #lang thing. I think that is time that is wasted. ***ng0_ is now known as ng0
<zig>I think one of the goal of racket2 is to reach users that are used to C-like syntax. I think, they miss the point. People do not want to use racket because it is a lisp, but because there is basically no software that use racket as language or compiler. It seems to me it is easier and better to try to proove and convince people that s-expr are the Good Thing by building software that is useful. <zig>from a programming language perspective, I think time would be better invested into things like typed racket, themed and take insipiration from haskell, rust, idris... that is code for which the compiler can proove more stuff and do more optimizations.. <wingo>all the language variations are enabled by #lang <wingo>i have thought for a long time that guile should add #lang, for its own reasons <daviid>wrt optimization, I quite like the CL declare way of things, where we can inform the compiler using declare form(s) (as opposed in typing the args in the arg list itself, which is terrible imo): (declare (fixnum n) (igore m) ...) _and_ (declare (optimize (safety 0) (space 0) (speed 3) (debug 0))) <wingo>types aren't mainly about optimization fwiw <daviid>but it helps the compiler, and that is very important, no? <zig>If one was going to add optional static typing, it should be backward compatible with regular scheme, that is type annotations should be no-op, if the host Scheme does not support static types. In this regard, I like srfi-145 approach: https://srfi.schemers.org/srfi-145/ <wingo>typed racket is essentially about being able to prove properties about your program. it is an additional expressive capability on top of untyped racket. sometimes those properties help the optimizer, sometimes they add overhead (contracts) <daviid>wrt 'gaining more users', I beleive it is more important to take care of 'little things' like default truncated printing in the repl/raised-exception/backtrace, providing a simple toggle mechanism to revert this to full print (which I beleive will almost always be the excpetion) - and other things probably, but this is a newbie blocker, in my experience <daviid>and i understand the theretical objectivem, but mine is purely speed <wingo>then you would avoid interaction with untyped scheme :) <wingo>hard to do in a composable manner <daviid>zig: declare is backward compatible, since you use it or not ... <daviid>wingo: i just hope 'we get there', declare is a good way to get closer, imo <daviid>i hadprogam fster in cl then in C <spk121>(I did like coding in Ada back in the day. Best language ever for strong typing.) <daviid>but i want to remain in scheme, just wish one day we can declare type and speed space ... options <daviid>*speed, space, debug ... options so the compiler can optimize 'on demand' <daviid>wingo: I beleive the dclare way of things will allow guile to acheive 'full speed' in a composable manner <jcowan>daviid: If your objective is solely speed, you should be using Chez rather than either Racket or Guile. (Racket-on-Chez will probably not be faster than existing Racket: the main motive is maintainability by cutting down the amount of C.) <daviid>jcowan: goops is the key ... and i'll remain onnscheme, i als beleive that speed should be not mine, but our objective, and, optional, hence the 'declare way of things' <jcowan>Oh, I see. Well, speed is a very good objective, but there are others. That's part of the reason why a hundred Scheme flowers (almost) bloom. <jcowan>Some people obviously value flexibility and debuggability first. <daviid>sure, but speed became guile's objective startig with 2.0, and is now more important then ever, you can see how many post we'had the last few weeks just about this (comparing other schemes ...)f <daviid>jcowan: the 'declare way of things' is 100% compatible with your claim <jcowan>Declaration and inference, yes. But I'm talking about whether an implementation is *optimized* for speed or not. SBCL supports the CL tuning knobs very well, but I know of no equivalents to them in Scheme. <jcowan>I should say, in any Scheme implementation. <wingo>people who want to quickly compute members of the mandlebrot set might prefer guile ;) <jcowan>Put not your faith in benchmarks. <daviid>jcowan: I don't see any theoretical limitation for guile, being a scheme, to be able to have and us a set of declare optimization options, both type and spce, speed, debug, that would 'forbid' to become as fast as a cl implementation, once we have an AOT of course <daviid>zig: unlike you, i have zero interest in this 'declare way of thing' to be compatible with other scheme <daviid>it should be for guile, and the guile compiler <jcowan>Neither do I. But there may be practical limitations in retrofitting this into the Guile code base while maintaining the original objective of being embeddable in desktop apps <daviid>only practicle ... i trust our maintainers to get there with a certin ease <zig>declaration should be opt-in, not mandatory. Unlike theme-d, it should not require learn a new syntax to declare types or contracts or whatever. <jcowan>sbcl for example is not embeddable because it needs to own the memory model, so it can call out to C but can't be called from C. <daviid>declare does not require any new syntax either <zig>Then, it seems like what I have in mind. <jcowan>In practice, if you want a CL embedded in your C app, you go to ECL; in your Java app, to ABCL. Neither of which delivers the performance of SBCL. Changing that is a Small Matter Of Programming <jcowan>(that is, easy to describe but too big to be practical unless you have huge resources) <jcowan>Like changing your favorite Fortran compiler to accept Cobol too. <jcowan>There is a parallel dialect of CL called *Lisp, which we know is pronounced "Star-Lisp" because there is a section in the manual called "*ting up *Lisp". <manumanumanu>drakonis, wingo: about getting closer to racket: I am approaching feature parity with my for loops :) A bunch of things are not really the same, since racket has a bunch of generic interface nicities, but the bulk of the loops are there. When I thought I was done, alexis went on and wrote for/foldr which has me making the loop-emit macro more general. <wingo>so i updated the web site to have 3.0 be the current major version, in anticipation of later this week <wingo>helps to get a bit of this cvs tomfoolery done early <wingo>lmk if anyone spots an issue <jcowan>wingo: Still not building on cygwin, per my post to guile-deve@ <wingo>probably will ship 3.0 without cygwin support then, there has been no debugging on cygwin <wingo>jcowan: does it work if you compile with GUILE_JIT_THRESHOLD=-1 set in the environment? ***terpri_ is now known as terpri
<jcowan>build worked in Cygwin with JIT disabled (as above) <jcowan>Can't run it on this corporate box <jcowan>anyway, it doesn't prove anything much, it's just Linux, as long as you aren't trying to call an unsupported syscall <manumanumanu>Just curious about how I would best run guile on windows. ***cbaines_ is now known as cbaines
<daviid>manumanumanu: i use msys2, which has a guile package <dsmith-work>I need to verify new guile builds and runs on my beaglebone black. 