***codemac` is now known as codemac
<void-pointer>Is there a good what, while staying in pure scheme, to inclement and decrement reference counts of an object (scheme equivalent to the C functions scm_gc_protect_object and scm_gc_unprotect_object) besides using FFI on libguile from scheme and hoping loading the library ends up referencing the current guile environment? <void-pointer>Curious question for those who have been around Guile for a few years <void-pointer>I heard about guildhall and looked it up and found that the project was effectively cancelled. <OrangeShark>void-pointer: I think not enough interest. I see people here mentioning once in awhile to try to revive it though. <void-pointer>OrangeShark: thank you. Depending on just what features it was trying to have, it could have been a massive undertaking. Took a look at PyPI's source and it was huge. I would guess that Chicken's is much smaller since they are building off of existing version control software. <void-pointer>Kind of said guile doesn't have something like those, yet (maybe one day) <davexunit>and it's much better than any language specific package manager <void-pointer>I've been tempted to try guix. Got to work around my current distro and not Frankenstein it too much. My hardware will sadly not let me use GuixSD (unless it takes way less time to compile standard packages than 10 years ago on gentoo, it would be a laptop cooker) <janneke>void-pointer: using GuixSD does not require you to build anything <janneke>void-pointer: GuixSD has binary substitutions and that works quite well <davexunit>I think the guildhall is still important for sharing pure guile code in a OS-independent way (guix only runs on GNU/Linux) <davexunit>but a lot of us aren't eager to work on guildhall because we use GNU/Linux and just use Guix. <OrangeShark>I think one benefit of a language package manager is the fact that it sort of enforces a similar package format. <void-pointer>Also, just going to say, it has proven tough to figure out how to use autotools for guile. High bar of entry. That and I really don't find Guile's current autoconf (at least, those in 2.1.4) to be satisfactory. <janneke>void-pointer: what's required beyond running ./autogen.sh? <janneke>(eh, after doing something like `sudo apt-get build-dep guile', of course) <janneke>that would be `guix environment guile' on GuixSD <OrangeShark>janneke: I think he means writing the files used by autotools <davexunit>I once started work on a 'guild init' tool that would autogenerate some of this stuff <janneke>yeah, i'm sure guix or a spinoff will fix this sh/m4/perl/make mess some time soon <davexunit>package managers should be conflated with build systems <davexunit>many programming languages make this mistake and the result is painful <davexunit>I've seen many a ruby application that depends on a package manager at runtime <davexunit>autotools is still the best way to build software <davexunit>a basic Makefile.am and configure.ac for guile projects is really quite small. <zaquest>why would any application depend on package manager at runtime? i mean unless it, well, manages packages <janneke>davexunit: great if autotools make you happy, it's been bothering me for over 20 years and i really want something that makes more sense <janneke>(and yes, it's the best we have at the moment) <davexunit>no one has been able to make anything better than autotools <davexunit>I think autotools has the correct philosophy about how a build system should work <janneke>i tried and failed and now regret i did <davexunit>for users building the software it's already a good interface <janneke>i think that caching intermediate results on disk is a big engineering mistake <davexunit>m4 needs to go. if you could write some scheme code that compiled to the configure script and makefile it would be much better. <janneke>for developers hitting bugs, requiring them to hack deep into huge m4 macros or perl stuff, it's a nightmare <janneke>the concept and user interface is great, but that's not autotools, autotools is just one implementation of the gnu maintainer guidelines? <janneke>why generate insanely difficult and unreadable makefiles if simply requiring GNU make and using its featurea would enable you to directly write small and crisp ones? <void-pointer>I was more referring to trying to distribute guile based packages, have it find the right guile or guiles, get the right tools for that guile or guiles, build the go files, and place the scheme and go files in the right places. Also, integrating some sort of unit testing. Aols <void-pointer>Getting some of that to work was tricky. Got a long ways to go to get it all working. <davexunit>janneke: every "small and crisp" makefile I have ever seen is "small and crisp" because it leaves out tons of important things <davexunit>same for every hand-written configure script <janneke>void-pointer: if you build in a chroot, what'- there to find? <davexunit>you aren't really supposed to read the configure/makefile that autotools makes. for all intents and purposes it's a binary. <janneke>davexunit: yeah...unless there are bugs <janneke>i just really dislike the idea of generated code <janneke>possibly my fault for trying to cross build lilypond and all its dependencies to all kinds of possiblbe platforms... <void-pointer>Well, I have guile 2.0 installed from my distro and put guile 2.1.4 in as well myself. What I am working on doesn't yet work with 2.0, so I have to make it find the 2.2 tools instead of a mix. GUILE_PROGS, if it finds a program named guile and guild with no suffix will declare victory and move on so it is hard to get the GUILE and GUILD variables pointing at the 2.2 tools if the distro defaults to not using a suffix for 2.0 <void-pointer>In the end, I just used GUILE_PKG to get the version and then the pkg-config macros to pull values for GUILE and GUILD from the pc file <janneke>void-pointer: so you're not building in some kind of chroot? <void-pointer>Not distributing, so was just trying to get it working without one since that is what I have the most experience with (that, and it would need to work in both cases in the end) <OrangeShark>void-pointer: shouldn't you be able to do GUILE_PROGS([2.2])? <OrangeShark>you might need to use the latest m4 from guile and include it in your project <void-pointer>I have not had luck with that (telling it to explicitly look for 2.2) yet. I end up just getting a configure script that returns an error because it looks first for a program named just guile, which in my case is aimed at 2.0, so when it looks at the version it sees a mismat h and returns an error <void-pointer>I will try the M4 file from savannah later, when I get my laptop back and report back on it. Maybe try to do a bit more digging. Also considering writing a macro to find the cache directory for go files (haven't found one yet, but it won't be that hard since I just have to run guile with a query expression for it) <void-pointer>I had originally thought getting this all setup would take little time, so I decided to do it and then found it took a lot more. Getting a bit distracted from the actual project, but oh well. <void-pointer>davexunitand janneke: you both suggested that there was a better way <void-pointer>I am curious about these ways. Chroot one in particular since I don't see yet how it would help, so I definitely stand to learn something <janneke>void-pointer: i used deboostrap chroots and semi-chroots with lilypond's gub build system...but now i'd just recommend guixsd <janneke>(or even guix on top of your gnu/linux distro) <void-pointer>Got it. I will try that. Get it working in a better and cleaner environment and only later try to figure out how to get it working in more varied environments once the rest is working well <void-pointer>And perhaps more importantly, focus on such details if and only if the project or pieces of it are ever worth distributing to anyone else <void-pointer>As I said, I got needlessly distracted because what I thought would be a one hour problem turned into something a lot bigger and I kept thinking just one more hour <janneke>well, you've been able to witness the amount of frustration i still carry with me wrt automake/libtool -- at least it surprised me, i need to do something with that ;-) <void-pointer>There is a lot of anger about it. I do understand why. I have not had to deal with the tools that extensively yet, so I don't have it yet. It is a giant mess. But for me, still a nicer mess than writing my own fully capable configure scripts and make files (I do do that one some simple projects where it doesn't have to be portable to every system out there) <janneke>for the records, autotools are great enough to get me frustraded -- home grown configure scripts or kludges like cmake can only make my cry <lluis>how do I "play nice" with the GC when passing an SCM object to a C function that's gonna hold onto it even after returning? I'd like to do it from within SCM code <wingo>(define my-saved-objects (make-hash-table)) <wingo>(hashq-set! my-saved-objects obj #t) <wingo>could change in the future, that will work with all guile versions tho <lluis>thx! that's what I was thinking, I just wanted to know if there was any GC function for that :) <lluis>and can I apply some code optimizations of my own only to selected procedures? (those passed as an argument to a function of my own) <void-pointer>That is oddly related to a question I had yesterday - is there a way to call the scm_gc_un/protect_object functions directly from scheme so as to avoid the overhead of having to stuff the items in question into another object or using the ffi on libguile and hoping one can get it to work in the current environment <lluis>wingo: I want to apply a very specific low-level optimization to code of procedures/lambdas passed to one of my procedures <wingo>void-pointer: same question, same answer :) <wingo>lluis: use a code-walking macro perhaps, dunno <lluis>wingo: the full story is that I have a dynamic binary instrumentator that is now extensible with guile (yay!) and want to do some very simple jitting for very simple user instrumentation callbacks <lluis>for more complex callbacks (for all of them now) I simply upcall from my C framework into the user's SCM procedures <lluis>any pointers to code-walking macros? I'll check if these apply to awhat I want <void-pointer>Thank you for the answer. I had a feeling I was going to have to do that method or do a bit of C extending for the project <jmd>I have noticed that if I change the definition of a srfi record which is exported from a module, guile neglects to rebuild dependent code - thus resulting in odd error messages. Is there any way to mitigate this problem? <jmd>(yes, I have read all sections of the manual where one might reasonably expect to see this explained) <davexunit>objects created using the old record type have a different type identifier than objects created with the new record. <davexunit>so trying to use an accessor or predicate on objects of the old type will fail ***masoudd_ is now known as masoudd
<davexunit>they cannot be magically transformed into objects of the new type. <jmd>davexunit: Would it not be reasonable for the .cache to be rebuilt in such cases? <void-pointer>If it did update them, it would be a procedure with a huge side effect, which would be bad in most cases <davexunit>FWIW, GOOPS classes can be changed on the fly <davexunit>the OOP system is more dynamic in this regard. <davexunit>if you redefine the record type <foo>, you are overwriting a bunch of stuff for a previously defined type named <foo> <davexunit>but the names <foo>, foo?, make-foo, etc. now refer to a different type <davexunit>and that is why you'll see "Wrong type argument" errors <davexunit>define-record-type makes *new* types, it does not mutate existing types. <jmd>It makes sense, but doesn't make it any less annoying (not to mention confusing for the naive user) <davexunit>it's only annoying if you come in with the wrong expectations <davexunit>so the manual or something could better prepare people for the reality <void-pointer>Now, one could make their own record type that does have that behavior (or, was pointed out, use GOPS) <davexunit>"do you want all existing objects to be converted to the new type? use GOOPS" <jmd>Also, is there a way I can get my error messages to go to a different terminal ? My application puts the terminal into raw mode, so it's hard to actually read them when something goes wrong. <davexunit>to a log file that you can tail or something <void-pointer>Wasn't talking about changing the srfi records type. A really terribly way would be to make one's own record type whose define record procedure looks in a table of already defined records types to see if it is a redefinition. Tables are kept of each instance for each record type. So, if it is a redefinition, it can then try to convert all instances of the record type to the new one while making the new one. The make instance pr <davexunit>from what I've read of the struct implementation, this wouldn't work. <void-pointer>table. Would need a destroy instance procedure to keep from filling up memory if one kept making them and hope the user uses the procedure <amz3`>void-pointer: you message was cut <davexunit>there's so many hard to answer questions if you go down this road <amz3`>I'm not sure I understand all of it, but it seems hard <amz3`>void-pointer: what are trying to solve, seems like problem XY <void-pointer>The struct implementation doesn't have to support it. Records can be made with lists, values, and keywords/symbols/strings/etcofchoice for the fields <void-pointer>Just saying that one could do this, not that it would be wise <amz3`>one can do a lot of things ;) <void-pointer>I think this is a great example of what a recent article I read was trying to get at <davexunit>in the future we'll be able to have struct fields with fixed types that the compiler can perform optimizations on <void-pointer>Lisps are powerful enough to make it really easy to make half baked ideas work just enough <amz3`>the kind of macros your are talking about I can't write <amz3`>hence I think your statment is not as true as it seems <void-pointer>I guess it needs an added caveat "assuming some level of macro knowledge" <void-pointer>Trickiest thing would be the conversion procedure. Already got ideas on the rest. That is the one that is making me scratch my head. <void-pointer>Well, the old instances of the record being defined have to be converted to the new definition <amz3`>void-pointer: AFAIU define-record-type is kind of "troll" magnet <amz3`>every one and else has an idea about a better define-record-type <jmd>davexunit: So after I change a record-type have you any suggestions how to proceed other than rm -rf ~/.cache/guile ? <amz3`>for instance, guix has it's own define-record-type for good reason (it allows to name fields in constructor and inherit from another record) <jmd>Well doing that seems to fix the problem for me. <amz3`>void-pointer: there is also another one called srfi 99 which is define-record-type* which allows to define mutable or immutable records in *one* line <davexunit>the problem you are having is that you've broken your ABI <davexunit>so yes, you need to recompile the modules that have been affected <amz3`>void-pointer: like (define-record-type* <foo> field-one field-two field-three) <davexunit>jmd: ABI breakage can happen when you change a macro but don't re-compile the code that uses that macro, which has happened here. <davexunit>so you'll want to 'make clean' or whatever you do for your project <void-pointer>My only gripe about r6rs records is that I can't specify, as is, copy semantics for get procedures. set-car! and set-cdr! are things and I want to make sure I have a record with immutable data so I can't accidentally screw them up later. Got a work around though (yay for selective exporting of module functions) <jmd>davexunit: (set-current-error-port (open-output-file "errors.txt")) Doesn't seem to affect where the stack trace goes. <jmd>Neither does with-error-to-file make any difference :( <codemac>I can't seem to succeffully redirect stderr into a port in guile ***micro_ is now known as Guest44612
***ecraven- is now known as ecraven
***siel_ is now known as siel
***C_Keen is now known as C-Keen