<mwette>wingo: my html5 parser is written in CPS (in the classical sense) ***jao is now known as Guest89262
***Guest89262 is now known as jao`
***jao` is now known as jao
<wingo>sneek: later tell mwette where is your parser? :) <manumanumanu>Wow. The computer had been feeling sluggish for a while and I ran top. My wifes login showed chrome using 76% cpu and 6gb memory (on an 8gb imac from 2016). Her account had been inactive since early january, but chrome was logged into facebook. Something there was doing weird stuff and was pegging several cpu cores at 100%. No wonder compiling guile master took so much time yesterday :D <lloda>(vector-set! #(1 2 3) 0 0) does signal an error at least <lloda>try what I wrote a line above yours <lloda>I'm just not sure if this is true of every case, like compiled/interpreted etc. <lloda>it was a while ago manumanumanu <lloda>I remember having to patch my C++ array conversions b/c guile wouldn't give non-const * anymore from certain Guile arrays <manumanumanu>It is a bit of a shame that you can't make immutable vectors from guile. <lloda>you can in C, just not in Scheme <lloda>well there is no interface, I'm just used to poking in Guile <lloda>it's just a bit in the various objects <lloda>what do you think would work for interface? (make-immutable ...) ? add a mutable-* version of every constructor out there? immutable by default? <lloda>some stuff does have immutable versions, like records <manumanumanu>Racket does vector->immutable-vector and vector-immutable. <lloda>that would be trivial to add tbh <manumanumanu>make-immutable seems icky since you might have already passed it somewhere where mutability is expected <lloda>still it could be left to responsible use <manumanumanu>i'd say immutable constructors like immutable-vector and vector->immutable-vector is the most sane. <lloda>vector->immutable-vector is the same as make-immutable isn't it? <lloda>also I'd prefer vector-immutable to immutable-vector haha <lloda>there's already immutable-vector? in Guile <rekado>I found that (current-filename) does not work in Wisp source files when using the Wisp reader with LOAD. <rekado>this is odd because the Wisp reader uses READ internally, and that should record positions (including the filename). <lloda>the mod immutable error isn't raised inside primitive-eval, only inside compile <lloda>I don't know where to go to fix that ***jao is now known as Guest14472
<jlicht>wingo: amazing blog post(/talk that I could not attend) :-) <lloda>want to remove all the contiguous fluff in arrays.[hc] <lloda>isn't used and never will be <wingo>lloda: you are the array boss :) compatibility is the only constraint, and that can be worked around with replace/deprecate/remove <lloda>im bulldozing atm, figured I'd do the deprecations later or I'd never get to it <lloda>but the contiguous flag was never used anywhere nor documented so I don't think it's user visible <lloda>am curious about bytevectors tho, b/c I think those are always contiguous yet there is a contiguous flag as well <wingo>i think that's for when the data is allocated inline <wingo>well, data contiguous with header words <wingo>but i understand the confusion :P <lloda>there are only so many words <lloda>did you see my question above about immutable vector? why don't we get mutation errors with primitive-eval? <wingo>lloda: didn't see that question. could it be that a vector produced via `read' doesn't have the immutable flag? <lloda>the exception is throwin with (compile) but not with (eval) <lloda>thx for the pointer, I'll look there <lloda>but the note would be wrong if the mutation doesn't raise error with primitive-eval, wouldn't it? <lloda>i.e. Guile still fails to detect the error, sometimes <wingo>lloda: i think the right fix is to have a separate read function, unfortunately :/ besides returning syntax objects, it would be sure to mark vectors as immutable <wingo>i am not sure we can change `read' as it has other purposes <wingo>and for primitive-eval, it is perfectly possible (though horrible :P) to do (primitive-eval `(vector-set! ,(vector 1 2 3) 0 42)) <lloda>I'll leave the patch there for the time being then <str1ngs>daviid I have another issue but it's not something I want to bother you with since it uses features from unstable webkitgtk. But maybe I can do some digging myself. I have a signal closure that should pass WebKitUserMessage as an argument. but instead it's passing a boolean. Can you point out the code that handles closure arguements? <daviid>str1ngs: the <closure> class, methods and procedures are in (g-golf hl-api closure) <str1ngs>daviid: great thanks will check that out. <daviid>str1ngs: a closure instance parameters are GValues, those are handled in (g-golf gobject params-vals) <str1ngs>okay will dig through there in the next couple of days. <daviid>the procedure that 'prepares' the input args is prepare-g-value-in, in (g-golf hl-api closure) <str1ngs>also FYI in regards to link hovering and updating a control. WebKitDOMGTK is deprecated and JavaScriptCore should be used instead. I'm using web extension with WebKitUserMessage . but it might be possible to just use run_javascript and JSValue. I'll look into this more. it's not something I actually need but some of the principles are nice to know academically. there are bits I might use later. <str1ngs>unfortunately JavaScriptCore leaves a reliance on javascript :( <daviid>where is the WebKitUserMessage definitin? <str1ngs>I have a guix webkitgkt-unstable package <str1ngs>WebKitUserMessage makes message passing from the WebKitView and WebKitPage much easier . without the need to roll your own DBUS service. <daviid>str1ngs: a WebKitUserMessage is a gobject subclass, so if yu can import the typelib, even if unstable, g-golf should handle it 'fie', just like <gtk-window>, ofr a <clutter-actor>, afaict at least <daviid>a signal that use those should assume it receivs a goops instance, and you should have nothing to do, because g-golf will find and pass the pointer to the GObject instance, and if it is a returned value, will receive a/the GObject instance and retrieves the goops instance for you, and return it ... <str1ngs>right so for that has been my experience accept for this case. maybe it's an issue with the typlib and not related to g-golf at all. C is fine though <str1ngs>it's not that important. I just created a custom signal and connect to and emit my custom signal from C and then g-golf handles the custom signal surprisingly :) btw g-signal-new would be a nice touch later down the road. :) <str1ngs>my method adds an extra layer to the signal is all <daviid>str1ngs: you could peek the value you receive from webkit, by changing tempo this line