<DeeEff>lloda: seems straightforward enough, but I'm not sure I'm understanding how it's binding things. Why, for example, are all functions defined as pointer->procedure, instead of foreign-lambda or something? <DeeEff>I guess in this case it's dynamic-func, by still why the pointer->procedure afterwards? Does pointer->procedure stop you from having to use dynamic-call? ***linas_ is now known as linas
<DeeEff>Are you referring to GDB? In which case, no, a breakpoint is a breakpoint <nalaginrut>I think trap require certain condition, but breakpoint doesn't <DeeEff>nalaginrut: I think there might be some problems in how the latest guile-colorized works <DeeEff>because I noticed problems in rxvt-unicode-256color <DeeEff>hrm, yeah. I'm finding some weird issue since upgrading from 0.0.2 -> 0.0.3 where if you type past the 40 or 50 character part it freaks out and all the text blanks out on the input line <nalaginrut>so you find it strange when you use C-p to get the history instructions in REPL <nalaginrut>if so, I think I encounter the same problem too, and I think it's related to the new colored-prompt feature <brieweb>I just want to walk through a function <nalaginrut>brieweb: I'm sorry but I haven't had the chance to hear all your question ;-) <DeeEff>nalaginrut: that's exactly the bug <brieweb>I would like to walk through a function <nalaginrut>DeeEff: yeah, it's painful bug, but I don't have idea what it is at present, I'll look into guile's prompt code <DeeEff>it may be readline as well, I never tried disabling it <nalaginrut>brieweb: sorry I can't understand 'walk though' in this context, can you elaborate it? <nalaginrut>DeeEff: but it's fine when there's no prompt-color, I hope it's not a problem with readline, dunno <brieweb>I would like to single step through the following function <DeeEff>nalaginrut: it appears to be a problem when using guile-colorized with readline. However, (nala colorized) from nala shell works fine, as do the old colorized versions. <DeeEff>did you use ^[[A or ^P in a control code anywhere? <brieweb>as you can see, I am calling it in the repl, and I want to single stole step <nalaginrut>brieweb: just set a breakpoint to the function name <nalaginrut>then you can use ,n to step the next instruction <nalaginrut>DeeEff: there shouldn't be any control code since it's just coloring, I'll take a look <nalaginrut>the bug has big possibility in generate-colored-prompt <DeeEff>hrm, I'll look at it, but I seriously doubt I'll know what it is. <nalaginrut>I recalled that I RESET it after colored the result <DeeEff>oh? specific line? I'm looking at it right now. *nalaginrut still has no idea for the bug in guile-colorized <lloda>pointer->procedure is used to convert types. Without the ffi, you need to do SCM -> c types conversion on the C side of the call. <lloda>you'd also need to register your functions from the C side, because Guile's dynamic-call can't pass arguments and it ***wleslie_ is now known as wleslie
<lloda>well, I should say it's more to declare the types than to convert them, because you can have them be SCM, but that requires a Guile aware library on the other side, of course <nalaginrut>DeeEff: I think it's because the colored-prompt is longer, so it occupied some chars but you can't see it <nalaginrut>when it's printed out, you just see a shorter prompt <nalaginrut>because the bug only appears when there's newline in your input... <nalaginrut>and I found another bug in master, run (1) will halt ***wleslie_ is now known as wleslie
<nalaginrut>ok, it's strange when readline & colorized both enabled, the console window will be 80 chars only <nalaginrut>hmm...seems related to the 'longer-prompt-string' issue... <davexunit>paroneayea: they dropped your name in that ^ <cluck>there's no pressure when the product is good and we all know bipt's work is great :) <bipt>civodul, wow! :D was not expecting that <cluck>tbh i'm more concerned with all the undeserved grumpyness going on with e-devel threads related to guilemacs <davexunit>yeah, we know that guile is a solid foundation, but they remain unconvinced. <davexunit>we shall see. just gotta keep doing good work and being nice, I guess. <paroneayea>nathan said something about "it's a good day when you get to research lisp and scheme" on the pumpiverse recently, or something <davexunit>I'm loving all of the attention guile is receiving. happy to be a part of this community. <rlb>I don't fully understand the "strings" debate -- I'd be inclined against having properties on every string in guile at the base, so naively I'd be planning to have something built on primitive strings that included properties. And then it's more of an emacs-side decision how to handle them, with the possibility of pulling good bits into guile if/when appropriate? <rlb>(speaking just about the properties issue) <civodul>bipt: i don't understand why people are again debating about #nil, it seemed to be mostly under control to me, no? <civodul>mark_weaver seemed to have doubts, though <davexunit>rlb: yeah, it seems like properties are for another data-structure that uses strings <rlb>davexunit: though I suppose you could consider handling it more generally... I haven't thought hard about it, but (for example) a hypothetical clojure dialect would need metadata for symbols/collections/etc. https://clojure.org/metadata <paroneayea>davexunit: in emacs, strings carry around properties all over the place <bipt>civodul, i don't think it will be an issue at all for elisp. it could prove troublesome for r[567]rs scheme programs, maybe <rlb>but I think I still might want the lowest-level strings to be more efficient (unless you could implement it in a way that was basically free when there was no metadata) <rlb>metadata/properties/whatever-some-other-language-needs <paroneayea>syntax highlighting is handled by embedding properties on strings... the orgmode agenda stores information about each item via properties... <rlb>also, are emacs string properties normally a lot of data or a little data relative to the size of the string? <davexunit>paroneayea: yeah, I guess I just don't see the need to unify emacs strings and guile strings <paroneayea>davexunit: I think it makes sense to have a data structure above guile strings that handles them <bipt>davexunit, it's pretty inconvenient for scheme and elisp to interact under the current system, due to the need for explicit string conversion <bipt>having generic string operations might be enough <civodul>paroneayea: look, you spawned all that chatting around guile-emacs! :-) <paroneayea>civodul: I've been pushing the conversation on it intentionally ;) <rlb>bipt: that's what I was wondering... <davexunit>bipt: similar to how guile's number procedures are polymorphic? <bipt>yes, and operations like string-append can do implicit conversion <rlb>davexunit: I'm assuming you'd want an emacs string type that responded to all the "normal" string operations... <rlb>(but the implementations also would do "whatever's appropriate" to the properties, assuming there's any relationship) <bipt>it's not quite enough since emacs allows non-unicode characters, but it might be easier than converting guile to use utf-8 all at once (at the cost of some performance) <davexunit>I wonder how that would work from a cleanliness perspective, though. baking in support for emacs strings in core guile... <rlb>davexunit: wouldn't have to be in guile core would it? <rlb>guile core would just have to make the string operations generic <davexunit>I guess I just don't know how that would work without invoking GOOPS <rlb>the implementation of the emacs string type and operations could be in the elisp (or emacs) world <rlb>davexunit: I was assuming goops I suppose <davexunit>(maybe that's the answer, but I shy away from GOOPS) <rlb>(or some other lightweight dispatch) <rlb>of course, right now I don't know that much about goops (potential) efficiency either. <paroneayea>davexunit: do you fear GOOPS from ghosts of object oriented past/present/future haunting your functional abode? <davexunit>but maybe just using the generics stuff without classes would work really well for this string problem. <rlb>I suspect full, clos-style systems may tend to be heavier-weight, but I'm sure it depends on the system, and the other relative overheads. In the clojure world, they take a pragmatic approach and provide two systems -- one that's designed for the common case that follows the jvm fast-path (protocols), and another that's a real generic system (multimethods). <rlb>For most purposes, protocols are sufficient (and faster). <davexunit>hmm, I wonder if guile should have a similar feature. I don't know enough about the topic. <davexunit>ooh, I can actually save stuff to read later now. I set up a free replacement for 'read-it-later' called 'wallabag' recently. <rlb>davexunit: and I'd imagine the only reason guile would want the distinction is if it was clear that an additional, more restricted system could be substantially more efficient, when it was appropriate. <cluck>i know most people laugh at the thought but i suspect strings will eventually become trees, for a small constant slowdown price it gets us hierarchical content (ie. lots of metadata space for free) easy navigation/access/modification, flexibility (functions need only watch and prune relevant nodes) and the regularity and predictability of the structure lends itself nicely to automated management (store, retrieval, backup, versioning, <cluck>it's a no brainer really, like good GC <cluck>(let the machines do ALL the work \\o/) <rlb>if string operations become generic (in some fashion), no reason you couldn't have more than one underlying structure... <ijp>which operations? most of the vector operations are not that useful on strings <cluck>supposedly this is where zmacs was heading in the later days just before symbolics went under <ijp>generic slicing a la python might be useful, I guess <rlb>I'd like to have immutable strings. <rlb>hmm, or are they already? <ijp>but literal strings are, or will be <ijp>I remember having to fix the docs, but I think it still confuses people <rlb>jvm/java strings are immutable, but "simple" (i.e. contiguous vector underneath) -- but there was a big change recently -- substring used to share, but now it doesn't. People who were expecting O(1) substring are in for a surprise now. <cluck>meh, it's not like java can get any worse <ahills>haha, just wait until oracle's had it for a decade <cluck>oracle probably could use the extra sales of server hw that will come from jave becoming slower <rlb>not fond of java, but the openjdk jvm's been useful <cluck>we can't do taxes here without java :| (the gov here distributes and uses an applet to file them) <cluck>(most people that have to deal with serious filing just get an accountant [and have them run the java]) <cluck>you can, if you want an even worse user experience <cluck>(our bureaucracies are very good at inflicting pain, skillfully) <paroneayea>though I'd love to be wrong, and for guile to become the universal VM anyway :) <cluck>i believe guile has a good chance at becoming the ubiquitous gnu vm but for that to happen we'll have to become way more welcoming and tolerant (sometimes even with idiots that are wrong) because for any community to grow and last there needs to be space for diversity and divergence <davexunit>I think we're quite welcoming. always room for improvement, of course. <cluck>otherwise we'll just end as a bunch of fools that believed a half dozen devs and rms <ahills>does gnu need an "ubiquitous vm"? <paroneayea>guile could certainly use more outreach, at least. <cluck>ahills: i personally believe it does <davexunit>but when people show up to #guile, I know that we're quite friendly and helpful. <cluck>also, don't provoke the naysayers like kastrup ;) <paroneayea>#guile has been welcoming, except for one memorable troll encounter where I think there were no ops in here <paroneayea>but that was the only time I can think of since I've been paying attention <cluck>*... become much more useful ...* <paroneayea>but guile could use more users, and in getting more users, it would be good to encourage a diverse group of newcomers :) <davexunit>trolls happen from time to time, though it's very rare here. <cluck>ahills: software suffers from network (and compounding) effects, programs become much more useful when they can interact with each other (big and small) and doing so in a single universal way removes big burdens from the user <davexunit>that one instance is the only serious one that I can recall from over 2 years of lurking here. <cluck>(sorry, link dropped, dunno if you saw the full message before) <paroneayea>a universal VM would be nice, if possible, but what is probably more important is to have a variety of people writing applications using guile <paroneayea>and not nearly as much proportional use to how featureful it is <davexunit>my limited experience is that things are slowly but surely picking up. <paroneayea>people do *crazy things* with emacs lisp. If there were an even more powerful engine underneath... <davexunit>useful guile libraries have been cropping up lately <paroneayea>and you could say "but guix", but installing guix on a workstation right now isn't easy :) <davexunit>but I'm not the right person for that job. any takers? <cluck>i think emacs and gcc might be potential entry points, if we want to reach the common man we'll need to get a browser to use guile :) <paroneayea>davexunit: we should try to get more excitement drummed up at libreplanet about guile <paroneayea>bipt: interested in proposing a guile-emacs talk? <davexunit>I need to submit a talk proposal about guile/guix <davexunit>but libreplanet is mostly non-technical so I need to work with that <paroneayea>davexunit: maybe I should talk it up to libby next time we chat :) <davexunit>"transducers" seem like nothing more than srfi-1 minus the list args. <paroneayea>if there are open spaces at libreplanet, I usually run a mediagoblin hackathon <paroneayea>maybe on one of the other days, do a guile hackathon? <davexunit>that would be cool. it all depends on what work I get assigned, I guess. <davexunit>I know that I'll be running around like crazy, most likely. <paroneayea>yeah I guess you have that "job" thing attached to libreplanet ;) <davexunit>but if I can choose some things to do, helping with an intro to guile or whatever would be excellent. <davexunit>I will propose a session in any case, and I'll see what happens. <davexunit>probably about guix and it's role in the GNU project. <ahills>is the fsf website written in scheme? ;) <davexunit>probably going to move to drupal since everything else we do runs on it basically. <ahills>use django instead, at least it makes your work easier <davexunit>drupal is actively developed, supported, and easy for non-technical staff to use. <ahills>well, PHP is actively developed and supported, but it's still a gaping security hole on any system running it... <ahills>better drupal than wordpress, I guess... <davexunit>right now, the free software world runs on PHP for web applications. <davexunit>paroneayea is taking steps to change that with his mediagoblin project <davexunit>and there's a few ruby/rails, nodejs, etc. applications now <davexunit>but more often than not, a free software web app runs on PHP <ahills>why not python/scheme/ruby/other sane languages? <davexunit>simple: PHP is the most popular, a lot of people already know it, and there's tons of libraries <paroneayea>ahills: python/ruby/node users contribute to free, permissively licensed libraries, but write proprietary webapps for their startups <davexunit>though I did see that company Knodium using chicken scheme. that made me happy. <ahills>ok, adding "guile web framework" to my todo list <ahills>right after "find a new job", etc <ahills>duck duck go brings me to the starcraft 2 wiki... probably not the same thing <davexunit>it looks pretty neat, and nalaginrut has been pretty hard at work on it. <ahills>hmm, maybe I should go back to getting libgc to build against musl so I can have guile 2.0 <davexunit>I have some disagreements with some of the design decisions, but it still looks quite cool. <cluck>wow, rms has not kept up with sw security in the last few decades: "You're talking about character encoding, but the message you responded to was about whether to put text properties in GUILE strings. The two issues are unrelated." <cluck>davexunit: what problems are you having with zope/plone? (genuine curiosity, they've been rock-solid whenever i've bumped into anyone using them. far more secure than drupal too) <davexunit>cluck: it doesn't use a SQL database, but it's own ZODB format. <davexunit>it's very slow compared to other CMS software <davexunit>it's very difficult to debug errors in my experience <davexunit>I have several tickets pertaining to hard to reproduce bugs <cluck>davexunit: i know about zodb <cluck>davexunit: i know it doesn't solve the blob vs. sql issue but it should help with speed a little <cluck>paroneayea: come on, object databases aren't *that* bad. you should save that "ugh" for mentions of php <paroneayea>cluck: I've worked with enough zodb and pickled object databases (Miro 1) to ugh at it :) <cluck>paroneayea: i reserve my ughs for sql injections and xss snafus courtesy of php/asp/jsp, etc <cluck>i rather deal with crummy slow dbs than insecure ones