<mark_weaver>aleix: guile ports automatically keep track of the line and column. you can get them with (port-line <PORT>) and (port-column <PORT>). ***add^_` is now known as add^_
<aleix>for some reason, i just rechecked and the different with and w/o updating column and number (in the record) was only 80ms from 0.22s to 0.30s <aleix>may be i was running non-compiled version, as at some point i was seeing a 2s difference <aleix>in any case, great, port-column and port-line is much better! <aleix>mark_weaver: with the port-line and port-column and getting rid of the parser record (which i only used to keep these two values) i just reduced > 50ms ***fangism is now known as fangism-hungry
<mark_weaver>ZombieChicken: to be honest, I don't know off-hand. guile 1.8.8 is ancient history as far as I'm concerned. why do you care? <mark_weaver>ZombieChicken: well, I'd highly recommend upgrading. <ZombieChicken>I am just learning Scheme. According to others here, there isn't a serious reason to upgrade since I'm doing all of this using SICP as my book <mark_weaver>Fair enough. Guile 1.8.8 should be fine for SICP. But ooc, what distro are you using? <mark_weaver>I think no one has gotten around to unmarking it. Guile 2.0.9 is quite stable. <davexunit>ZombieChicken: 2.0.9 is what you should use. it's the latest release. <ZombieChicken>mark_weaver: unstable in gentoo just means no one has asked for it to be stabilized or there are bugs still floating around related to it <ZombieChicken>It would take a simple entry in package.accept_keywords to unmask it <mark_weaver>I don't have time for this now. Take my advice or leave it. <mark_weaver>but for starters, we know of tons of bugs that have been fixed in 2.0 but will never be fixed in 1.8 because we'd long since abandoned that code base. <davexunit>ZombieChicken: guile 2.0 introduced a lot of major changes that are worth having. everyone here uses the 2.0 series. you'll have less problems with it. *nalaginrut is filled with admiration of 44 stars of guile-2d <davexunit>I need to do some more work on it. I've been too busy playing with guix and whatnot. <davexunit>oh wow it's late. bed time. work in the morning! <dsmith>ZombieChicken, Yep yep. 2.0 is the way to go <dsmith>I vaguely remember an article in Byte magazine about a Forth or Lisp machine processor design. Had the same pinout as a 6502. <dsmith>Dr Dobbs Journal of Computer Calisthenics and Orthodontia. Running light without overbyte. <ZombieChicken>nalaginrut: I think you can buy old Lisp machines off eBay and some antique computer sites <ijp>bigger, faster, with better access to the internet! <ijp>a guix based GNU OS could be cool, though we'd need to get rid of the unix part <nalaginrut>well, I have my hackspace&techshop and a bunch of hardware hackers, I want to build a lisp-machine from scratch, just for fun ;-P <ZombieChicken>silly question, but couldn't you just run a lisp interpreter atop an existing kernel and be pretty close to a Lisp machine? <ijp>depends how you define a lisp machine <nalaginrut>the great fun is not to run a lisp interpreter in a virtual machine <ZombieChicken>ijp: true. Iirc, a true Lisp machine is an all-in-one system with a kernel written in lisp, running lisp code, on hardware designed to run lisp <nalaginrut>yes, the point is 'hardware designed to run lisp' <gzg>nalaginrut: Actual LispM, or a Pseudoiip-machine Os? <nalaginrut>in principle, it should be actual-lispM, with a lispOS <ijp>gzg: I think it makes more sense to create a new one, than live 20 years in the past <gzg>Would you design actual boards, processors, etc, or repurpose them? <nalaginrut>if possible, I expect an ARM+FPGA board, and the FPGA should be programmed as lisp-machine <ijp>gzg: if you insist on doing the hardware, an fpga makes the most sense (for now) <mark_weaver>nalaginrut: the Mixxeo board from the Milkymist project might be a good starting point. <ijp>but designing an efficient processor is a complex task *nalaginrut searching at once... <mark_weaver>nalaginrut: Milkymist is a free hardware design for a system-on-chip, including CPU, many peripherals, and good graphics I/O. <mark_weaver>it runs on the Milkymist One, and the soon-to-be-ready Mixxeo, which is hardware with an FPGA for running the free system-on-chip design. <mark_weaver>it's not a mass-produced item. very limited quantities. <gzg>If I'd go all in at this point, I'd probably want all documentation and the implementation to be in Lojban. That's idealism on-top of idealism though... <mark_weaver>but there's no way to get low-cost for what you're talking about. <ijp>gzg: well, I disagree, but since we are pie in the skying... <ijp>I spend a lot of time thinking about what computing would be like if we could scrap unix and windows <nalaginrut>yes, the developing cost is definitely for lisp-machine, but I want to limit the hardware cost <ijp>it is very hard to do, because those colour basically everything we do <nalaginrut>nowadays hardware is cheap in China, especially in Shenzhen, so I believe there's a way to go <ijp>but I already gave that rant on #emacs earlier <ijp>ZombieChicken: go through /usr/bin/ and make a list of all the programs that have lost you data <ZombieChicken>other than miswielding rm once or twice, I don't think I have <ijp>shell globs can really mess you up <nalaginrut>alas, the problem is, if I choose FPGA, I may have to use quartusII in pirated way <ijp>unix never gets something right when it can standardise the wrong three times <mark_weaver>nalaginrut: building your own computer and design from scratch is a *huge* undertaking. I really don't think you'll ever get off the ground unless you start from the existing project. <ijp>go through /etc/ and count how many different configuration file formats there are (I'll give you a hint, it isn't one) <ijp>how many different kinds of regex syntax are there? <ZombieChicken>can this be summed up by the New Jersey approach vs. the MIT approach to design? <nalaginrut>mark_weaver: yes, I want to use a working & cheap board <ijp>ZombieChicken: that's way too crude <ijp>ZombieChicken: everything is a file, which is why we have rmdir... <nalaginrut>to me, limit cost anyway is the only possible way to start a hack project <ijp>oh and of course X, where the server is the client <ijp>at least I haven't had to explicitly edit xorg.conf in the past 3 years *gzg wonders how a hobby LispM would compare, speed-wise to Unix-likes, on modern hardware. <ijp>unix and windows have taught us to make do with not second-best, but coming in last with a "at least you tried" sticker <ZombieChicken>gzg: Depends. I'd imagine it would be as good if not better than everything else <ijp>gzg: terrible, because it would be designed by someone who hacks software, not hardware <gzg>ZombieChicken: On a hobby machine ... <mark_weaver>no, the modern hardware will kick the ass of any hobby LispM. <gzg>ijp: I'm asking more-so, I'm hoping it wouldn't be painful to use. <ijp>mark_weaver: I haven't found a copy online, but there are some neat implementations of pop count in "beautiful code" if you can get a copy from someone <ijp>Henry S. Warren Jr. "The Quest for an Accelerated Population Count" <ijp>I suppose I've never really implemented multithreading <gzg>At least on such a hobby device, you probably wouldn't have to worry about making it multiuser. :^P <ijp>preemptive, not cooperative <ZombieChicken>If you don't like *nix and Windows, have you ever tried to design your own kernel and userland <ijp>the shell is easy enough to fix, most dynamic programming langauges do it better <ijp>modern gnome and kde are okay <ijp>and of course, I live in emacs <ijp>the filesystem situation is weird <ijp>e.g. we've had versioning filesystems for decades, and no-one uses them <nalaginrut>however, people has abandoned dynamic-languages, picked up static-languages, now they're crazy for dynamic-language again <ZombieChicken>That trend wouldn't be related to execution speed, would it? <ijp>nalaginrut: funny thing is, I'm moving in the other way <ZombieChicken>I don't know about Scheme, but I know CL is dynamic unless you specify something as a static-type. That is a reasonable approach in my opinion <nalaginrut>so I wonder if people will hate modern hardware soon... <nalaginrut>ZombieChicken: no, I'm talking about lispM issue <ijp>nalaginrut: plenty of people have hated x86 for some 20 years <ijp>but if you can make something fast and cheap people will work around its problems <ijp>it's the basic principle behind fast food <nalaginrut>hmm...that's what I said, cheap is key point, and the second is fast... <ijp>well, there the explicit decision was to reduce speed to make it cheap <ijp>the gaming industry on the other hand makes its hardware cheap by selling it at aloss <nalaginrut>we built an Arcade with raspberryPI, running various emulated games with a nice Arcade controller, the speed is just so so, but it's the cheapest Arcade <nalaginrut>well, I should use capacity/price, which is more fair <gzg> Bed-time. Peace people! AFK. <nalaginrut>hmm...try to dream, someday a 60$ lisp-machine filling all your lispy habit... <nalaginrut>...itwaste of time to invest energy on this proprietary crap <nalaginrut>...it's waste of time to invest energy on this proprietary crap... *nalaginrut dropped quartusII <taylanub>Oh, `define-inlinable' actually creates a syntax keyword ? <taylanub>Is there agreement on that module imports should be immutable ? The module could still be replaced as a whole at run-time, and having a module's users mutate bindings of it seems like a very bad idea. <dsmith>ijp, What are your thoughts on plan9 ? (to go along with your OS rant) <ijp>I have ignored it on the basis of "once bitten, twice shy" *nalaginrut received a shared license of Xilinx, so he can continue his lispM-on-FPGA adventure... <dsmith>I've *wanted* to try it, but I never seem to have HW that it runs on <ijp>taylanub: what do you think? <dsmith>ijp, I suspect it is much more consistent, re config files and other things. *ijp tosses taylanub a biscuit *taylanub dances happily. <ijp>dsmith: actually, I think it may have been the utf8 usenix paper that mentioned plan9 was the first unix descendent to have a consistent regex syntax <taylanub>Does it really fuzzy-match, or does it perhaps just match "seen" as a special-case ?.. <sneek>From what I understand, dsmith is Da Masta <wingo>you sure that's not a parsing bug, that it sees the "seen" command and then decides to do something with the line? <sneek>I last saw jao on Sep 25 at 02:08 am UTC, saying: ijp, thanks! (i'm incorporating version checks to geiser). <wingo>dsmith: does sneek still leak? <ijp>I have no idea what it is I said to jao there <dsmith>I havent restarted it in about 4 weeks <ijp>that password is so secure I can just paste it here freely without worry <wingo>i'm just wondering how you found out my password, is the thing <wingo>if yours isn't, it will be changed for you <wingo>dsmith: what's the left and right number? <dsmith>wingo, Been running for a month and a half <wingo>so the vsz went down over 15 minutes? <nalaginrut>wingo: alright, are you talking about passwd of sourceforge? I never tried it <dsmith>pi@berry /tmp $ tail -5 sneek-rss.log <wingo>dsmith: so does rss ever go down? <dsmith>vsz grows by about .5 meg a week <dsmith>wingo, I can mail you the whole log if you want to look at it. <dsmith>But I think it's time to stop logging. <wingo>dsmith: can you mail me the source of the bot, or link to it somewhere? <wingo>i'd like to find the leak :) <wingo>maybe your leak is sql-related <wingo>so i think the leak might be in gs_sqlite_exec <wingo>it does a scm_to_locale_string, which mallocs <wingo>and nothing will free that afaik <wingo>also depending on your use case you could leak sqlite databases -- probably better to attach a finalizer that closes the database, if needed <wingo>and possibly you could call sqlite_close multiple times <dsmith>Been a long time since I looked at that <wingo>so if you allow sqlite-closed to be called, it's probably best to null out that smob <wingo>but then you have to check for that in sqlite-exec <wingo>note that scm_procedure_minimum_arity isn't free either <wingo>but maybe that doesn't matter <wingo>at least any memory it allocates will get collected <wingo>finally you can use scm_from_locale_string directly, without doing the strlen variant <wingo>which probably should be scm_from_utf8_string btw <wingo>and you can use scm_call_3 instead of scm_apply_3 <dsmith>I think I originally wrote that with the older api (gh_* ?) <shanecelis>Hmm... I'm having a weird issue where when I connect to a REPL it'll sometimes cause my app to crash. I think I've identified why. I have a SMOB that normally works ok when its created and free'd on the same thread (a graphics object), but when I connect to the REPL sometimes it'll be free'd on a different thread which makes the app crash. Any ideas what to do? <mark_weaver>both standard malloc+free and libgc are thread safe, so I doubt the problem is there exactly. probably something else is not thread safe. <shanecelis>I'm using a wrapper over OpenGL, in there it's dying on glDeleteBuffers which probably isn't thread safe. <stis>evening folks!, Yeah, I'm finally satisfied with guile-log's dynamic function implementation! <stis>the cool thing that a cache friendly application can find any matching combinations of 10000 entries in about 0.4 mu s <stis>e.g. it will not be the bottleneck in most cases <stis>oh it's also functional e.g. the state can be stored and restored at a whim <dsmith-work>why is this accepted: AC_SUBST(GUILE_EXTENSION_DIR, `${PKG_CONFIG} --variable=extensiondir guile-2.0`) <dsmith-work>and this complain: AC_SUBST(GUILE_SITE_DIR, `${PKG_CONFIG} --variable=sitedir guile-2.0`) <davexunit>stis: so guile-log is a library for bring prolog concepts to guile? <davexunit>I would have assumed that it was for reading/writing log files. *dsmith-work shakes fist at autotools <stis>davexunit: you are not the first one asuming that :-) *davexunit says that in hopes that an answer is delivered faster than he can duckduckgo :P <ijp>kanren is a relational programming language embedded in scheme <stis>the referencefor kanren is reasoned schemer <ijp>the name literally means 'relation' 関連 <stis>but yuu should already know kanren in order to make something out of that <stis>prolog is traditionally stack based and kanren keeps data in a assoc manner. <stis>both have advantages / disadvantages <ijp>stis: I never bothered to figure out the name until asumu hinted at it to me on #racket a few months back <stis>kanren beeing a better programming interface though. And prolog is, ... odd <stis>with this you can take a prolog program, compile it and use the funcitons in kanren and vice verse <stis>kanren has the concept of interleaving "and" and interleaving "or" which are pretty cool. <stis>guile-log also have logical programming versions of delimeted continuations. <shanecelis>All right. I found a way to fix my issue where a SMOB free happening in the wrong thread crashed my app. Here's my fix: Stick the SMOB in a guardian, such that it's not free'd during GC in other threads. Then in the proper thread's tick function, empty the guardian, then call (gc). Any better ideas for preferred thread SMOB freeing? <wingo>shanecelis: sounds plausible to me ***alexei___ is now known as amgarchIn9
***fangism-hungry is now known as fangism
<taylanub>(begin (define (test) (vector-ref #(0 1) 1)) (set! vector-ref 'error) (test)) ;should this not error ? <wingo>in general set! on primitives doesn't work right <taylanub>Then my stable-2.0 (2.0.9.20-...) build from a couple weeks/months ago has a bug, or ?.. <wingo>yep, there is a bug somewheres <wingo>i mean, i know how that happens, but it's unclear how to fix it <wingo>so i don't know what the fix is <taylanub>Of course it's kind of sad that when it works right, we will get less optimization. :P <taylanub>I've been trying to think if there's any way to both make such things optimizable, and retain the run-time flexibility we have. (If anyone has resources on the topic, would be appreciated, else I'll just be re-thinking the wheel.) <wingo>there is no general solution short of jit compilation <taylanub>Hrm .. maybe this is crazy talk but I can imagine "compile-time references to (or copies of) objects" which result in private bindings in compiled code that remain unaffected by later redefinition of whatever variable was used. (Not sure if I'm being clear at all.) <madsy>When instantiating a new shmob from C++, do I really have to use cm_gc_malloc? <madsy>My object isn't copyable, so the only time it's freed is during garbage collection, which calls the callback <madsy>It would be easier if I could use new and delete <taylanub>madsy: Are new and delete for stack-based memory management ? <taylanub>If yes, then note that your object's lifetime might exceed the lifetime of the stack frame in which it's created. <madsy>taylanub: new and delete are C++ keywords that do the same job as C's malloc() and free() <mark_weaver>madsy: if your objects are allocated with malloc, they will never be freed by the garbage collector. <taylanub>Maybe see the documentation of `scm_gc_malloc': (info "(guile) Memory Blocks") <madsy>Then what is scm_set_smob_free() for? Isn't that callback responsible for freeing all resources associated with a shmob? <taylanub>madsy: If I'm not mistaken, it should free resources that the smob *references*, which aren't inside the allocated region. <mark_weaver>yes, and it gets called when there are no more references to your object, but *only* if you object is allocated by scm_gc_malloc (or similar) <mark_weaver>yes, the idea is that your smob can reference memory allocated using plain malloc, or things like file descriptors or whatever. if your object is no longer referenced, the GC detects that, and then calls your registered smob free function so that you can release all the resources referenced within. <madsy>Okay. So I only use cm_gc_malloc on the structure itself then. <madsy>So except for references to other SCMs, all other pointers can from from new/delete or malloc/free <taylanub>The ones you manage manually via your smob's initialization and freeing functions, yes. <madsy>That explains a lot. Thanks :) <mark_weaver>madsy: it would be better to use the GC to allocate as much as possible, for various reasons. <mark_weaver>let me illustrate a problem that can happen otherwise. <mark_weaver>Guile's bignums are like the smobs that you're proposing: there's a small header object allocated using scm_gc_malloc, and that references larger chunks of memory that are allocated using plain malloc. <mark_weaver>the problem is that the GC doesn't run until the heap gets fairly full. <mark_weaver>but it's only looking that the GC-allocated heap. it doesn't know about memory allocated with plain malloc. <mark_weaver>so you can end up with a situation where you have a massive amount of garbage, and thus you use huge amounts of memory, but the GC doesn't run because as far as it knows, you haven't allocated very much. *taylanub takes note, too. <madsy>I see. I'll keep that in mind. <mark_weaver>there are ways to manage it, but they are somewhat ugly and prone to problems. <mark_weaver>so, if I were you, I'd be looking into using GC for as much as possible, rather than as little as possible as you seem to be aiming for. <madsy>My problem is that if I have (or should) use cm_gc_malloc on my biggest allocated blocks, I have to reimplement the structures of a whole library and copy the data over, just to allocate it the right way <mark_weaver>now, you can arrange to make 'new' and 'delete' use the Boehm GC, transparently. <mark_weaver>I never use C++, so I can't tell you exactly what you need to do, but I know that there's a way. Boehm GC was designed to allow it. <madsy>The structures from assimp contain allocated arrays and trees, so I don't see how a dumb copy would work <wingo>madsy: if you allocate using malloc or friends in response to some call from scheme, perhaps via smob creation, you should call scm_gc_register_allocation <taylanub>madsy: (By the way you've been consistently misspelling it; it's "scm_gc_malloc", not "cm_gc_malloc".) <wingo>unless you are using scm_gc_* to allocate <madsy>taylanub: Oh, thanks. I probably missed the marker when I copied the name from my emacs buffer ;-) <wingo>also scm_malloc == malloc + scm_gc_register_allocation <wingo>it's confusing, there is scm_malloc which is malloc, and scm_gc_malloc which is the gc-managed thing <mark_weaver>yeah, scm_gc_register_allocation doesn't solve all the messy problems of finalizers etc, but it at least lets the GC know that memory is being allocated so that it will do a GC. <mark_weaver>wingo: isn't there a way to make normal 'malloc' and 'free' transparently use the Boehm GC allocation functions? I thought there was. <wingo>mark_weaver: i think there is, yes <wingo>though it seems like a bad idea to me <mark_weaver>I'm not sure if it was based on a header file or a shared-library trick. <mark_weaver>hmm. well, okay. I'll take your word for it. I've managed to avoid C++ for about 15 years :) <madsy>mark_weaver: You should take a look at C++11, if it's useful in your domain. It has some amazing stuff now :) <mark_weaver>I believe that languages should be much simpler, and that the complexity should be instead in the libraries. <mark_weaver>I don't doubt that it has amazing stuff, but I don't want to use a language that would take me months of study to clearly understand what it's doing. <madsy>mark_weaver: Hah, I feel exactly the same way about Scheme and Common Lisp ;-) <mark_weaver>well, I can sympathize with the fact that what you already know seems simple, and what you don't know seems complex. but by any reasonable metric, Scheme is vastly simpler than C++. <wingo>woo, eval.go in rtl bootstrapping... <taylanub>I just realized that my "compile-time references to objects" crazy talk is essentially the same concept as static linking; we could say that in Guile, modules that use each other do link to each other dynamically, and we lack static linking capability. :P <mark_weaver>except that for some special procedures which we call "primitives", where we go beyond even static linking, and do something more analogous to inlining. <wingo>whee, psyntax bootstrapping too <wingo>next up will be boot-9, some other day <wingo>then everything else should fall out <mark_weaver>that's great news! getting psyntax compiling is noteworthy :)