IRC channel logs
2015-11-03.log
back to list of logs
<daviid`>civodul: thanks for the guile-gnome approval support! <daviid`>davexunit: i cooked something for you :) wrt to script example <daviid`>davexunit: i like it because it is fairly complete, it gives you an opportunity to teach a very simpe macro, file tree walk, erros, catch exception [set-locale], verifying arguments ... cool! [not because i wrote it :)] also, i cooked based on a more complex real case: we use this scrpt to resize hundreds of thousands of images in the lab i part time work for <daviid`>it uses both match and receive [on purpose, it gives an oportunity to exaplain the diffs, when, why ... <davexunit>this reminds me that I've been meaning to write a guile script that uses oggenc to transcode my FLAC music collection into OGG for putting on my phone. <davexunit>tried doing it in Bash awhile ago, was a nightmare <daviid`>you should be able to use the 1 i just posted, changing the system calls, args check ... it is a good template, i think but review welcome of course <daviid`>davexunit: line 72 there is a tipo, it should be 100 [not 99], and line 264, let is ok, let* is unnecessary <davexunit>I'll hang onto the paste. I'm a little overloaded with other stuff to do at the moment. but I do appreciate this script! <daviid`>davexunit: it's ok, remember these 2 tipos when you'll look at it <cky>mark_weaver: I'll soon send a patch to the mailing list with the relevant changes to our codebase (except that in the Guile SRFI-41 port, I'll use case-lambda). <cky>It will, as a nice bonus, allow me to remove that crazy `list?` shadowing hack that we have in `list->stream`. <cky>I don't think my message posted (it was sent from a different email address from what I subscribed with). Just reject it; I forgot to put in a ChangeLog message in the commit message, which I'll add just now. <davexunit>I can't figure out how to say "match any string but this" with posix extended regexps <holomorph>use a regex that matches what you don't want and reverse your condition <davexunit>a multi-line comment is delimited by '#|' and '|#' <davexunit>and suffer whatever performance penalty I get but have something that works and is readable. <cky>davexunit: #| |# comments are nestable. So you can't use regex for this. <cky>davexunit: Let that be Zalgo's lesson to you. :-P <cky>Also your syntax highlighter needs to know how to deal with read macros. :-P <cky>As in, what read macros are active will affect how things are read. <cky>Oh, but it does, since read macros are allowed to reinterpret things however it likes. <davexunit>the reader macro #foo is just some symbol to the lexer <cky>You should at least know how to handle the common ones, like #u8(...), #u16(...), etc., as well as the #s versions. <davexunit>those don't need to be rendered any differently <cky>davexunit: But if you use the standard lexer, you'll be interpreting #u separately from 8 or 16 or whatever. <davexunit>I'm not using anyone's lexer. I'm writing one specifically for highlighting a variety of languages <davexunit>got something that works for nested multi-line comments <amz3>can I port 3 clause BSD software and change the license? <amz3>my understanding of the text: if the code breaks any patent its your problem <amz3>the only other implementation of css-layout is based on the facebook implementation <amz3>IIRC there is not other way to implement flexible layout system, without going through this "imperative" style of algorithm <amz3>There is declarative algorithms but they are not enough versatile <amz3>There is one such declarative layout system called GSS <amz3>but it doesn't support wrapping <amz3>Well, the great interest of css-layout aka. flexbox is that it can emulate any other layout algorithm <amz3>I mean, most layout algorithm. It don't support circular layouts <amz3>So i can use the same algorithm for layouting text and the shell <thorwil>if only everyone would use a constraint-based layout system, capable for websites, any GUI and even CAD applications <amz3>thorwil: GSS is a constrained layout, it does not do wrapping. I don't remember the name of the algorithm (the name of an animal IIRC° <amz3>flexbox is an answer to this debate about constrained layout vs declarative layout <thorwil>how would constraint-based and declarative be opposites? <thorwil>in any case, flexbox is the first sign of sanity in the history of css layout <amz3>s/delcarative/non-constrained <lloda>emacs doesn't handle well neither #| |# nor #; (at least on 24.3) <ArneBab_>amz3: We were looking for something davexunit could use to “show how Guile is a good language for learning programming.” <ArneBab_>amz3: you can use 3 clause bsd along with LGPL and the resulting derived work will be LGPL. <ArneBab_>amz3: if you want to be friendly, leave the BSD header in files you only modify and only add the LGPL header to new files (this means that your changes to the files you modify will be 3 clause BSD, too, but the creators of the original libaries will have much less reason to feel bad, since they will be able to reincorporate most changes into their work. <amz3>ArneBab_: I propose a mvc webapp <ArneBab_>amz3: how does that compare against other web frameworks? <amz3>ArneBab_: there is not framework, it's simple web app <amz3>sorry, i mean to say a todo app <amz3>mvc todoapp is a famous js competition <amz3>it's a pseudo-competition to compare js frameworks, I studied one or two. <remi`bd>MVC doesn’t always make sense in scheme/lisp <remi`bd>but the principle of a todo-list web app is cool <fps>does something like racket's ragg exist for guile? <ArneBab_>amz3: that’s nice — it shows the delays in the apps from clicking the link to being able to use the program. ← knockout criterium <davexunit>"while Andy Wingo steadfastly refuses to acknowledge this patch" <civodul>i'm impressed by the time and energy he puts in messages <taylan>ACTION suspects that emacs-devel is mostly people who *don't* have to work 8 hours a day in addition to trying to contribute to free software... <taylan>oh, it seems he replied (partly?) in response to me. now I feel guilty. <taylan>thought this was on e-d. :( guess I just won't feed the troll. <mark_weaver>wingo: sorry I've not been online much lately. I'm okay with you making a 2.1.x prerelease. <daviid>wow the 3 mainainers are here, party time! <daviid>mark_weaver: nice to see you back [not that you were away for long but...] <civodul>"how many maintainers does it take to change a light bulb?" <civodul>mark_weaver: we had a discussion regarding foreign objects vs. GOOPS, for 2.0.12 <civodul>(though i won't look into it until after the Guix release) <mark_weaver>Kastrup has an enormous amount of time to put into this because, last I knew, he lives on almost no money and basically works full time on what he wants to work on. similar to me in many ways, except that he doesn't have two kids around. <mark_weaver>(I don't have my own kids either, but am living in a house with kids) <mark_weaver>and, although it is in many ways a rewarding experience, I would strongly advise anyone who wants to do something significant with their lives to avoid having kids. <wingo>mark_weaver: hey no need to apologize to me :) <mark_weaver>and I'll go further and say that, IMO, if the human race is to survive and be free, it will take a *lot* of smart people dedicating themselves to significant work. <wingo>if there is a prize for being the absent guile maintainer, surely i will win it :) <mark_weaver>heh, well, I don't think it's quite so clear cut. all three of us have been distracted by other things, to say the least. <wingo>btw i got floating-point unboxing to work!!! <wingo>not sure if you saw that but i was pretty excited about that :) <wingo>i think it probably removes the pressure for any kind of nan-boxing work <wingo>because where it matters is mostly in loops and we can mostly unbox in loops <mark_weaver>yeah, but probably things have to be boxed when calling procedures that are unknown at compile time, right? <mark_weaver>so nan-boxing might still make sense on 64-bit systems at least <wingo>yeah, but i wonder how long the 48-bit address space will last... <mark_weaver>yeah, that's obviously the big downside of nan-boxing. <mark_weaver>we'd probably have to switch away from nan-boxing at some point <wingo>so the proper solution is dynamic inlining <mark_weaver>but on the other hand, if guile-allocated pointers were limited to a 48-50 bit address space, that might not be a problem in practice, because GC becomes difficult on that scale anyway. <mark_weaver>(I forget how many bits we'd have available for pointers without slowing down tag checking much) <wingo>i think we could do that -- it would just mean writing out the CPS data structures to an elf section and having a background thread look for inlining opportunities <wingo>but i don't think it will happen in the next couple years <wingo>we'd do native compilation first <wingo>and that's really close, fwiw <mark_weaver>right, so nan-boxing might be a reasonable stop-gap before we have something better <wingo>my one misgiving is that it's a bit of churn that won't be needed in the end. but yeah. <mark_weaver>I implemented it, and it wasn't too bad. relatively small patch. I guess I should dust it off and post it. <mark_weaver>the representation of most things didn't change at all. <wingo>davexunit: yeah, a simple native compilation isn't that much more work than bytecode compilation. there are some nits to figure out about stack management and how the native code would have access to runtime calls but it wouldn't be terrible. <wingo>mark_weaver: that's pretty neat :) <davexunit>I'm frankly in awe of just how good Guile is. <mark_weaver>wingo: btw, I've changed my mind about two things of note: I think that (* 0 <anything>) should probably be 0 <wingo>mark_weaver: you mean (* 0 <number>) <mark_weaver>and the other thing: in the past, I've been skeptical that natively compiling everything is a good idea, on the theory that the VM might be more memory efficient. I've changed my mind. <wingo>yeah sure, no strong opinions here <daviid>wingo: tx for the guile-gnome ftp-upload approval. I guess i will receive a note when it is active? <mark_weaver>I guess we should still make an effort to optimize for code size rather than speed for non-hot code, though. <wingo>mark_weaver: yeah getting the speed/size balance right is going to be tricky <wingo>mark_weaver: i haven't forgotten about the page alignment issue either; will fix for 2.1.2 i guess <wingo>istr we decided 64k was good enough for all architectures <wingo>daviid: i actually don't know :) <mark_weaver>sure, that's fine. the big things for me continue to be stuff like macro-introduced top-level handling, which as I recall we came to agreement on here on IRC but haven't implemented yet, and the issue of built-in thread synchronization for otherwise cheap operations like byte/character I/O. <wingo>yeah, still some things to work out. also GC for compiled code <mark_weaver>I know that the ball is in my court, so to speak, on the thread sync issue. I've just had trouble finding the energy to write up my latest thoughts on it. <wingo>istr your concern was more with the default behavior than the facility itself <wingo>so whatever decision we come to shouldn't be a huge change, if i remember the discussion right <paroneayea>mark_weaver: btw not sure if you got my message here on IRC earlier in the week, you told me when we were in boston to remind you about the stuff needed to land https <wingo>haha, the worst thing about coming back to irc is that everyone pounces on you ;-) <wingo>good to see you around tho and please don't feel any pressure from me :) <paroneayea>I think everyone wants https support in guile proper, tho! :) <wingo>now i just have to steel(e) myself for coming back to guile-devel :P <daviid>wingo: speaking of pouncing, could you grant me guile-gnome admin privs on savannah and answer Brandon Invergo <brandon at invergo dot net> wrt Guile-Clutter GNU Project [separate] page request, that would be awsome! <mark_weaver>wingo: btw, I agree with you that we should gain complete control over our garbage collector. there are many problems with relying on bdw-gc, and we're unlikely to get everything we need pushed upstream, and even if we did it would be years before we could rely on the new features being available on distros. <davexunit>seems to be a good example of forking and bundling. <wingo>davexunit: what do you mean? <wingo>you mean, of bundling instances, we have a good reason? <mark_weaver>I think davexunit is alluding to the fact that distros don't like when projects bundle libraries and modify them, and I feel as strongly about that as anyone. <mark_weaver>but, having said that, I'm not sure that GC is a good candidate for a library, honestly. <wingo>we've done really well with bdw-gc, esp. compared to what we had <wingo>but i think we can do better <mark_weaver>language implementations probably need to be more intimately integrated with their GC. <davexunit>I found it odd at first that Guile didn't have its own GC <davexunit>unlike every other dynamic language I knew of <mark_weaver>another thing is that I really think we need to leave open the possibility of having a moving GC at some point <wingo>maybe a mostly-moving collector... <davexunit>for example, Ruby has their own GC and they've done *tons* of work on it for the 2.2 series. <mark_weaver>and unfortunately, we've already taken some steps that will make that difficult, like telling people that they don't need to write marking procedures <mark_weaver>does the smob-replacement have any marking interface? I don't remember seeing one. <wingo>mark_weaver: it does in the sense that words can be marked as being raw or SCM-valued <wingo>not sure if that bit is exposed in the API but it's a property of structures and we can expose it when it makes sense to do so <wingo>mark_weaver: so actually the slots in a foreign object are not traced, by default <wingo>this fact is not mentioned in the docs :/ <mark_weaver>from my perspective, the new API is not fully baked, and has not had enough critical review. if not for that, I'd be glad to release 2.0.12 right now. <mark_weaver>how would you feel about reverting it, releasing 2.0.12, and then having a discussion on the list about what should do into 2.0.13? <mark_weaver>so, I can briefly talk about a few of my issues with the API <wingo>sgtm; only question is whether someone is willing to do the work of reviewing and/or patches <mark_weaver>it locks us into SCM values having the same size as pointers <wingo>i don't want it to be my api but the smob api is just terrible and guile needs something else. <mark_weaver>it relies on the user to make sure each entry in their struct is the same size as an SCM, which seems likely to result in a lot of non-portable code <mark_weaver>from the user's point of view, it seems like it would be much better to not require each field to be the same size. <wingo>you are advocating a data structure that can't be created from scheme <wingo>or if it can, it's not like any other data structure we have now <wingo>and doesn't integrate with goops <wingo>you prefer to use the ffi api? <wingo>so painful to have to revert all of that nice documentation :( <wingo>isn't the constraint that each field is the same size or smaller than an SCM? <mark_weaver>not necessarily the same API, but I just don't think it's going to work well to rely on the users to make all the fields of their structure the same size. I think users will end up writing a bunch of code that only works on x86_64, or doesn't work on MIPS n32. <wingo>are you imagining a platform in which pointers do not fit into SCM values? <mark_weaver>if we're going to rewrite an API that has existed in Guile for over a decade, it just seems like we should make something that's nicer for users and less error prone. <wingo>hm, i don't mean imagining in a pejorative sense <wingo>yeah dunno, i just wanted to build on structs because they already work well, they just didn't have a nice api <mark_weaver>no, pointers definitely need to fit with an SCM, but an SCM doesn't necessarily need to fit within a pointer. <wingo>mark_weaver: so in a struct each field is scm_t_bits wide <wingo>doesn't that suit your purpose just fine? not sure if i understand the concern <mark_weaver>suppose we wanted to make SCM values 64-bits even on 32-bit systems. I'm not saying that's necessarily the right thing, but suppose we did. well, that would no longer be an option after this API is released. <wingo>sorry if i am missing the details :) then each field in a foreign object would be 64 bits wide. <mark_weaver>because then pointers and SCM values would not be the same size <mark_weaver>so if we end up with a lot of code that uses this new API, and makes structures containing a mixture of raw C pointers and SCM values, the members are no longer all the same size. <wingo>that is fine as long as the unit size can hold either a C pointer or a SCM value <wingo>so if you set a field to a void* it casts to a uintptr, then zero extends as needed to a scm_t_bits <mark_weaver>well, your constructors take all initialized slots as void pointers. <wingo>let's say SCM is 64 bits and a pointer is 32 bits. setting a slot to a pointer sets the high bits to zero. this is ok, no? <wingo>think of each slot as being union { scm_t_bits, void* } <mark_weaver>but I admit that I may have a fundamental misunderstanding about your new API. <wingo>it exposes structs in what i hoped was a nicer way <mark_weaver>somehow, I was of the impression that users would make their own C 'struct' type, and then Guile would access the fields by index, assuming all members are the same size. <wingo>i think that is a misundersanding yes <wingo>there is no new foreign object type <wingo>the result of make-foreign-object-type is a vtable <wingo>and a foreign object is a struct instance <mark_weaver>okay, so suppose I make a foreign object with one SCM slot <wingo>also i realized a thing, it seems that guile traces "u" slots, so the docs are fine <mark_weaver>SCM scm_make_foreign_object_1 (SCM type, void *val0) <mark_weaver>now, I can't pass that SCM slot to 'scm_make_foreign_object_1' without losing bits, if SCM is larger than a pointer. <wingo>the API currently only allows you to access slots as void* or as scm_t_bits <wingo>because all slots are "u" slots <wingo>and even if you use the low-level scm_struct_ref api, then it reads the slot value as a scm_t_bits unsigned integer and then wraps that integer as an scm <wingo>using scm_from_uintptr or whatever <wingo>so the api doesn't really support you doing scm_make_foreign_object_t (type, SCM2PTR (val)) <wingo>but that's your problem because you did SCM2PTR to pass a SCM as a void* <wingo>not the api's problem, afaiu <wingo>could the misunderstanding be that you thought foreign objects were meant to hold SCM values? <mark_weaver>by using 'void *' as the argument type of initializers for scm_make_foreign_object_*, it is implicitly assuming that SCM values can fit within a void * <mark_weaver>oh, is it your intention that foreign objects should never hold SCM values? <wingo>mark_weaver: correct, foreign objects should never hold SCM values <wingo>their fields are traced by the GC so if you put a scm_gc_malloc'd memory block in a field it will get traced <wingo>but that's related to our other discussion, i think... <mark_weaver>although this doesn't allow for moving GC, because the GC doesn't know the layout of the objects pointed to from the foreign object, right? <wingo>i think we could add an api to fix this <mark_weaver>well, it allows the user to define marking procedures for smobs <wingo>ah yeah. but i think in a new api we probably don't want to support user-defined mark procedures. dunno. <wingo>you could describe the field layout precisely <wingo>and the gc could use the field layout to do what it needs to do <wingo>i.e. this is a tagged scm value, this is a gc-managed raw pointer, this is an untagged value, etc <mark_weaver>I don't think that's workable for lilypond's use case, which is probably something others will want to do as well, e.g. having smobs use C++ STL data structures containing pointers to other GC'd objects, etc. <mark_weaver>because the layout of the STL data structures is not something the user knows portably, right? <wingo>actually yes you can know the layout <wingo>the constructors of those Handle<> template wrappers end up adding roots to the GC <wingo>and has no user-specified mark procedures <mark_weaver>well, I don't know about STL, but in general, if users want to use arbitrary libraries implementing container data structures, they may not know the layout but may be able to write a marking procedure. <wingo>i don't trust *any* user to write a correct mark procedure :P <mark_weaver>lilypond has a large amount of code that depends on the semantics of our previous API, and that depends on being able to specify marking procedures. <mark_weaver>I think we'd need a very compelling argument for removing that functionality. <mark_weaver>the lilypond problem will not just go away. we still need to help fix it. <wingo>so one thing that you want to do in a good gc is mark from other threads. <wingo>running arbitrary user code from other threads is a *terrible* idea <mark_weaver>I'm willing to have this discussion, but if we need to have it and resolve it before 2.0.12 gets released, that will probably not be very soon. <mark_weaver>hence my suggestion to table this new API until after 2.0.12 <wingo>i agreed when i thought the fields were unmarked by gc -- but now that they are i disagree, it's simply a nicer api for almost all purposes that builds on already-established struct values <mark_weaver>sorry, I have to go afk again.. thanks for discussing... ttyl <nalaginrut>too bad, I realized that 'load' will be strange for relative path