<saul>Maybe not on Busybox/linux, but certainly on GNU/Linux. <ZombieChicken>if busybox is the userland, I wouldn't expect much else to be installed <saul>ZombieChicken, TInyCore is Busybox-based and it is fairly complete (but does not include Guile). <ZombieChicken>I didn't say it wouldn't have anything else, but I wouldn't expect it. Tinycore is a 'desktop' distro iirc <nalaginrut>it's easy to cross-compile Guile into embedded board <nalaginrut>hmm...it's been a while since I played it on embedded board, so I can't remember if it's uclibc at that time <dje42>anyone have an opinion on srfi 41 (streams, lazy lists) ? I was looking into it as a way of iterating over some gdb objects without having to create the full list first <ijp>well, it'll work, but it is in a sense suboptimal, because if you are generating it through somestateful process, then all the list elements have to be fully evaluated in order, and so you are wasting an indirection for each entry <ZombieChicken>Is there a simple, concise book covering Scheme, like K&R for C? <ijp>I forget how much K&R covers, but there is the little/seasoned schemer <ijp>though neither of those cover macros <ijp>or quite a few other things for that matter, like IO <ijp>but naturally, portable IO in scheme is rarer than the antartican phoenix <ZombieChicken>I'm interested in something simple so I could start playing around. I have SICP, but I'd just like something simple so I could actually play with the language a little bit faster <ZombieChicken>saul: Thanks. Not what I'm looking for exactly, but that is handy. <wingo>subrs are rtl stubs in master now <wingo>makes things slower in order to make them faster (?) <ijp>taylanub: it would be semantically incorrect to use one definition for old code, and one for new code <taylanub>Hrm, in a way this already happens for syntax and inlinable definitions though, or is that something different ? <ijp>by the time mutations occur, the syntax has been expanded away <ijp>if you did have fexprs, then you would need to undo them <taylanub>When you say semantically incorrect, do you mean intuitively, backwards-compatibly, according to a standard, ... ? <ijp>consider the simple factorial function (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))))) <ijp>what happens if you do (define factorial fact) (define fact list) ? <ijp>and then call (factorial 10) <ijp>don't evaluate it, tell me what you think it should do <bubble>I am trying to make a OOP version (with or without actors) of server-side scripting, woule I still need to take on guile-oops for that or is another OO system imminent ? <bubble>I am looking at seaside smalltalk for this <ijp>what do you mean by server-side scripting <ijp>that sounds like a basically meaningless term <bubble>What the "cool ideas" page says on gnu.org <ijp>the one which says "this page is old ignore it" on the top <ijp>there are no new OOP systems planned <bubble>what about the web scripting ? is it guile-www ? <ijp>use guile-www if you want, I wouldn't <ijp>taylanub: anyway, I chose a terrible example, that one =should= error <bubble>ok, I noted __builtin_expect, maybe make that into a AI. Then translating code for rtl to change archs would not be too bad <ijp>if fact could never set!, you could optimise the recursive call to jump right to the definition <ijp>this is not as frivilous an example as it looks, because you can e.g. bind a top level handler for the web server, and then change it dynamically <ijp>for a similar reason, you need to care about mutability if you want to do eta reduction <ijp>actually, there is another issue with eta reduction relating to call/cc but that isn't relevant hee <ArneBab_>ijp: (factorial 10) should then intuitively give '(10). <ArneBab_>ijp: but it could also give (whatever-fact-pointed-to-before 10) <ArneBab_>the former would be easier for beginning programmers, but both seem equally intuitive to me (nowadays) <bubble>wingo : May I ask where guile-figl gets its toplevel window ? Where the code for that is in guile ? <ijp>well, no, it errors, because the example was broken <ijp>so you try to multiply by a list <ijp>if you take the latter behaviour, then you can't have recursive loops that can be changed <ijp>and I gave the example of server handlers <ijp>the semantics of scheme are very simple, if you have a function all (foo 1), you look up the current value of foo, and try to apply it the the value 1 <ijp>if you have (lambda () (foo 1)), you need to make sure that it always refers to the current value of foo when that function is called <ijp>the purpose of optimisation is not to make code fast. it is to make code fast, _while_ preserving all the observable behaviours of that code <ijp>otherwise we can just compile every program to int main () {return 0;} and call it a day <ijp>if your code does something different after the optimiser is through with it, it hasn't been optimised, it has been broken <taylanub>ijp: I kind of didn't think of the possibility of a module set!ing one of its own top-levels that it declares as copy-on-write ... <taylanub>I'll think more about this later, sadly have to get to work now. :P <ijp>it doesn't have to while modules are open <ijp>you peek inside, twiddle about, leave <ijp>wingo: just out of curiousity, why are you removing glil, objcode &c <ijp>I don't suppose anyone else is generating it, but still <ijp>also, are you introducing any backward incompatible changes in treeil? <ijp>it'd be a shame to have to lose that chunk of the manual, it is one of the nicer parts to read <wingo>ijp: if a thing has no purpose, it should go -- i am removing the old vm too <wingo>there are tree-il changes, yes <ijp>that one could be annoying, since people do actually generate it <bubble>wingo : so if I understand, you need guild for an API <ijp>I'm just going to push that self-quoting vector change to the manual <gzg>bubble: Is it really? Not looking into it at all, I just assumed it was "guile output". :^U <ZombieChicken>Silly question; what is the standard file extension for a Scheme file? <gzg>ZombieChicken: *.scm *gzg really needs to stick himself in the manual one of these days. :^U <gzg>bubble: How long ago was "back in the day"? <ijp>I've never seen .s, but there is still code in the racket repos with .ss <gzg>Aw, I was still just a babe then. :^) <ijp>it was their preferred extension up until the name chaneg <ijp>ZombieChicken: 40 years <bubble>dialect in Dutch is "sublanguage", things with an accent <gzg>ZombieChicken: Lisp is a family of languages, Scheme is a sub-language, or "dialect". <gzg>bubble: Why are you always a half-a second ahead of me?! :^) <bubble>there's clisp for that in ftp.gnu.org <ZombieChicken>gzg: I know that. I was just wondering if there was something specific bubble meant by that statement <gzg>ZombieChicken: Will, I meant the initial response more-so and it's a figure-of-speech. :^P <ijp>today in stupidity, lookin in the version 1.8 info page <bubble>indeed, guile 2.2 needs more docs <ijp>well, that isn't the issue here <bubble>I think so, there's lots of new features <bubble>things such as guile-figl etc are packages devved for a better guile such as perl's h2xs <bubble>due to guild (old guile-tools) as I said <bubble>back in the day *lol* you only had bindings <ZombieChicken>Is there anything in 2.x that is would affect a newbie trying to learn scheme? <ijp>ZombieChicken: the basics are all the same <gzg>ZombieChicken: I couldn't imagine what. *gzg is writing an introductory text, to actually teach himself to a much greater degree. :^) <ijp>wingo: would you mind giving me a yes/no on my peval bug fix sometime this weekend? <ZombieChicken>bubble: My scheme book is SICP. I imagnine the new standard is newer than the book <ijp>guile does not support r7rs, nor is there any immediate plan to <ijp>nor will it matter for ZombieChicken <gzg>ijp: Well it's not even finalized yet, is it? :^) <ijp>no, and large never will be <bubble>I wrote snow for s48 a while ago, as a prototype <ijp>not that it should, but that's a whole other matter <ijp>gzg: I stopped being optimistic when I learned that not a single one of the r7rs wg took exceptions seriously <ZombieChicken>Would any of you say Scheme is moving towards a more standard enviroment? What I've read has said that Scheme is rather implementation dependant for a number of features <ijp>and jcowan and I have major, shall we say philosophical, disagreements over what it means for something to be a standard <gzg>ijp: Eh, I'm not well versed in enough in this world to really form a strong view either way; So, I'll take/leave your concerns as real potential problems. :^P <ijp>ZombieChicken: there are two major definitions, the one everyone outside of computing uses, and the one people in computing use <ijp>I take the former, he takes the latter <ijp>anyway, this is not your concern yet <bubble>maybe as ZombieChicken is reading, put something of a slib in guile which is r6rs <bubble>I don't know what that board is saying <gzg>For the sake of Guile and it's place within and relevant to the GNU system, I'm not particularly worried if we/they stay "upstream" in-terms of the standard as long as all the cool bits and bytes are implemented in some fashion. :^P *bubble goes back to his seaside scheme <gzg>bubble: Well, I mean this is an implementation more-or-less focused for/around the GNU OS and related projects, there's no real pressing need to have a large standard library to-which needs implemented , for other implementations, with a bit of work, could possibly, maybe do close to the same thing. :^P <bubble>true that's the industry versus the rest <bubble>continuations come to mind last std <ijp>you want to handle erros gracefully? tough luck <gzg>ZombieChicken: Not very; Certainly not comparable to CL. This is pretty much the 1st step in "correcting this" via the means of R7RS large. <ijp>gzg: that is not even close to true <ZombieChicken>I know CL covers a ton of stuff, plus there is asdl and quicklisp for various things. It is also a much more complex language <ijp>it's basically a rebranded srfi process <gzg>ijp: Good, if I'm spewing sand out of my mouth correct me; I should have prefaced this statement with "to my very limited knowledge". :^I <ijp>there is little obligation to support any or all or r7rs large, and they are springling on liberal doses of "implementation dependent" for good measure. don't want to accidentally have code work right on two different schemes. <ZombieChicken>Ok. how do I run a script with guile? Shebang doesn't seem to work <ijp>though you should get an error if you don't include it <ijp>do you actually have a guile at /usr/bin/guile ? <ijp>and which switches are not documented in --help? <ijp>1.8.8 is not getting an update *bubble notes his command line switches have gone <ijp>more to the point, it does mention -s <ZombieChicken>hence my questions before about the diff between 1.8 and 2.x <ijp> [-s] FILE load Scheme source code from FILE, and exit <ZombieChicken>Ok, this may sound strange, but is there a sane way to run a .scm file using sh ./foo.sm? <taylanub>ZombieChicken: "Sanely" I don't know but there's always hacks possible with shell scripts (or any executable) where the initial part of the executable file has some code that finds the executable itself, cuts out this initial part (currently being executed in memory), and the rest of the executable is some "payload" with which it can now do anything it wants. <taylanub>You can have self-extracting archives like that, and wrappers for different kinds of code, etc. <ZombieChicken>I could imagine some ugly code using heredocs and/or a self-parsing script <ijp>I have some shars lying around somewhere, I feel dirty whenever I remember them <taylanub>I've very recently seen someone use this mentioned hack, was on the Guile mailing list .. let me dig it out. <bubble>its something as py2exe for python ***anderson is now known as Anderson
<ijp>cky: ping. what is the state of the define-macro rewrites? <mark_weaver>ijp: I'm not so sure that R6RS is dead. It needn't be, if some good implementations continue to support it, and code continues to be written for it. <mark_weaver>ZombieChicken: why do you want "sh ./foo.scm" to work? That explicitly says to interpret ./foo.scm as a shell script. why would you want to do that? <davexunit>./foo.scm would work with the proper shebang <davexunit>is it possible to use generic functions without classes? <davexunit>generic functions seem really appealing to me for part of guile-2d's API, but I don't think I really need to use classes or other OOP things. <dsmith>davexunit, You at least need to have types to dispatch to the right function <davexunit>I'm trying to translate an idea that I have seen in many game libraries for object oriented languages. <dje42>davexunit: data point: generic functions work with smobs (which aren't real goops classes) <davexunit>I suppose I could also just my own hash table or something that maps a type to a set of procedures. <dsmith>davexunit, No, I don't think so. You can dispatch on smobs, like dje42 mentioned. <ArneBab_>davexunit: from what I saw about generic functions, it would be quite feasible to provide the generic functions as an api: something drawable is something for which the developer defined a draw function. <ArneBab_>davexunit: but beware: I’m very, very much a beginner here <ArneBab_>(define-method (draw (x <mythingi>)) … ) <dsmith>davexunit, Does class-of work with those record types? <davexunit>so I guess that means I can make generic functions like that, then. <davexunit>my other question is: does this makes sense to do here? <davexunit>I'm not sure how to do it otherwise. all of the scheme code I've written before this hasn't used any OOP. <dsmith>davexunit, If it makes it easier to read write and contemplate your code, sure. <ArneBab_>davexunit: what interface do you want to provide? <ArneBab_>davexunit: I think starting with the code a game should have would be useful here. Do you write a game while writing guile-2d? <davexunit>ArneBab_: I just write small example programs. <davexunit>I have a game in mind that I want to write, though. <mark_weaver>davexunit: in GOOPS, everything has a class, including primitive types like booleans and symbols. <mark_weaver>so yes, you can use generic functions to dispatch on other things. <ArneBab_>davexunit: I hope that I’ll be able to use guile-2d, though I have some structures I planned for my games which I’ll have to see whether they can be used with guile-2d <ArneBab_>davexunit: the current version is in python and the structure partially relies on python-features <ArneBab_>davexunit: 2 blocks of functionality: Interaction (GUI state, show GUI state, take input) and Logic (model state, take commands, give results) <davexunit>ArneBab_: I don't see why you couldn't that in guile-2d. <davexunit>it just might not have all the features yet to make it a pleasant experience for you. <ArneBab_>davexunit: with the interaction between both happening only from Interaction(UI state) to Logic(take commands) and Logic(give results) to Interaction(GUI state). <davexunit>ArneBab_: I'm currently trying to write an API for game states, which is why I have all of these generic function questions. <ArneBab_>davexunit: maybe I can provide some questions for that :) <davexunit>I would like to make a data type to describe a game state. trouble is, each state has different callback procedures and different data that it operates on. <ArneBab_>davexunit: where do you need which state? → actors with their own state, the level with actors as state + start and finish conditions. <ArneBab_>(many actors which interact and take their own decisions) <davexunit>I am writing game states as a high level concept to break up the main portions of a game. examples would be: main menu, battle screen, high score screen, etc. <ArneBab_>so a game state is something which provides a minimal API for the currently active part of the game (finer than level, but close)? <davexunit>the game loop will know the current state and will call update, draw, key-down, etc. using the callbacks for the current state. <ArneBab_>there I see two different kinds of states: full states (you switch to level X) and temporary states (you hit pause - goes back to the previous state on escape) <ArneBab_>davexunit: something like a stack of states which have 2 different options: switch to another state and leave state (goes back to the “higher” state). <ArneBab_>(that would be the minimal state switching API) <ArneBab_>sidenote: I misunderstood “game state” as something like the current score or the lives you have left. <ArneBab_>davexunit: a slightly complex topic: How to handle preloading of a potential next state. <davexunit>don't know. I don't see the need to preload really. <ArneBab_>the need is that you will want to avoid unecessary load times on complex levels <davexunit>that would be for the game programmer to work that out. <davexunit>preload assets on game load or be smarter about it in a game state. either is possible. <ArneBab_>the way how you handle pop and push can make that easier or harder *ArneBab_ made the mistake of making the state something which gets created on push → no preloading possible, except by using cludges like precaching data. <ArneBab_>people will do whatever is easiest, so the easiest thing to do should be the desirable thing to do on the long run ☺ *ArneBab_ sadly needs to get going <ArneBab_>davexunit: It’s cool to see you hack on guile-2d! <ArneBab_>(and I wish I had more time to help - but I try to help when I have some free minutes, even if it’s only by adding ideas which you might have to discard ; I hope they help anyway, if only to sharpen your idea of why you choose the path you take) *stis made a propsal to make vhashes thread safe <wingo>stis: what do you mean by "using the source as a standard lib" ? <stis>yes I'm pretty bad with words as you know. <wingo>i'm super-skeptical about many "just use C" strategies <wingo>the compiler will already give a big speed boost and i'm sure there are algorithmic things too that can help <stis>yes, in order to add C stubs we really need to know if vhashes are bottlenecks. <mark_weaver>stis: how did you come up with that "30x" number? what precisely were you comparing to what? <stis>vhash-assoc 1 .. 10 0000 <stis>vhash-then assq on the number 2000 <mark_weaver>but for the 30x faster version, did you add a VM instruction, or what? <stis>did that 1000,000 times and looked at the timings <stis>but I know that typically there is a 2x speedup for these objects using a VM op instead *wingo appears to have borked master, working on fixing it <stis>no, 30x is a target speedup, but a vm-op would probably be 20x. 30x is certainly possible with native compilation uiin guile <mark_weaver>there's no "typical" here. it depends on what the operation does. if the operation is "vector-ref", then the ratio of how much faster it gets will be a lot bigger than if the operation is very complex. <mark_weaver>in the scheme loop you wrote, a great deal of the time was probably spent in the loop handling: the counter increment, test, and jump. <stis>well vhash-assoc seam to take about 200 cycles here. My feeling is for that beast this should be a good estimate <wingo>heh, master is fine -- i had a locally miscompiled vlist.go here :P <stis>the scheme loops handles about 10M to 20M oiterations, I did 10M in my C loop <mark_weaver>it's really hard to make these kinds of estimates, even for those who have a lot more experience than you do. <wingo>master seems to be about 10% less memory usage currently <wingo>on a guile -c '(sleep 1000)' <stis>well these are the numbers I but it's not a proof, my experience says that i'm not to much off. But it is an aproximation <wingo>hopefully that will improve when more things are rtl-compiled <stis>Also I think as you say, using vlist/vhashes wrong, can have algoritmic problems. <mark_weaver>the other thing is that one must be very careful about concluding too much from super-simple benchmarks like this. in these simple cases, the cache and the branch predictor will be able to perform much better than they normally do in most real programs. <mark_weaver>a better test is to see how much is improves compile times, given that the compiler uses vlists and vhashes quite a bit. <stis>yep, but it's a good test if th working set is small, or if the working set are recent numbers. ANd i suspect that many logic programs has this propert <wingo>tough to test on master atm though, given that it's in so much flux... <mark_weaver>if one wanted to use the compiler to find out how much faster vlists are, one could use the profiler to see what percentage of time is spent in the vlist ops, while compiling a file. <wingo>it used to be around 10% i think <mark_weaver>or rather, how much time overall.. and then repeat the same compilation with a different vlist implementation. <stis>yep, my interests is in using vhases for guile-log/kanren <stis>I know that there the datastructure for the lookup are very critical. <stis>Especially when we get into nativly compiled code <mark_weaver>true, but also remember that when we have natively compiled code, then our current vlist/vhash implementation will also be native code. <stis>Yep, but not today :-) Time will come to move it over to scheme, but not now <mark_weaver>fwiw, I'm sympathetic to the position that vlists should be reimplemented in C, in fact I've proposed it before. If native compilation wasn't expected in the relatively near future, I'd still believe that quite strongly. <mark_weaver>but at this point it might be better to wait and see how well we can make the Scheme version perform with native compilation. <stis>and probably not with the first version of the native compiler can reach the speed of optimized C code. <stis>gcc is very mature and I worked quite hard at optimizing the code. <stis>I started with -O3 optimized code at 7x speedup <wingo>i would be happier if we could determine which parts are considered to be slow <wingo>if there are primitives that might be worth vm ops <wingo>but tbh i think doing C stuff on that code is the wrong thing right now -- the potential gains with the new vm and a better compiler are too much <mark_weaver>wingo: would it be possible to make a faster mechanism for calling out to arbitrary C code? <wingo>mark_weaver: the rtl stubs are faster i think <wingo>not hugely faster, but faster nonetheless <wingo>certainly some little inline caches would be appropriate... <mark_weaver>well, it might be worth thinking about whether we could have a specialized VM op for reducing the number of instructions in each of those stubs. <wingo>perhaps elide the switch, and instead trampoline through a function pointer <mark_weaver>another question is whether we could make a faster mechanism for calling out to specially-crafted C functions that would manipulate the RTL stack directly. <mark_weaver>basically, these would be kind of like RTL instructions, but outside of the actual VM engine function. <mark_weaver>I dunno if it's a good idea, but it just popped into my head and I typed it :) <dsmith>Would vlist/vhash implemented in C help the bootstrap evaluator? <cky>ijp: I'll work on it more today. I took today off to get my wisdom teeth extracted, but I'm feeling pretty chipper at the moment (long may that last). <ijp>cky: well, I'm not exactly in a hurry for it ;) <ijp>but I was peeking though the bugslist, and there is no "we've replaced macros foo/bar/baz", so I figured 'd ask <cky>I won't be posting to the bugs list just yet. I'll just be pushing my changes to a private branch. <cky>(Nice thing about having commit access. ;-)) ***linas__ is now known as linas
<dsmith>wingo, irreducible-loops-at-level warning. What does it mean? <add^_>Hm, I'd completely forgotten that it was Friday.. <civodul>wingo: (system vm coverage) works with RTL programs? <civodul>i guess that's a sign that it's in good shape ;-)