<dsmith>chibi scheme is supposed to embed well ***hugh_marera_ is now known as hugh_marera
<dsmith>sneek: later tell R1ck77 "Chibi-Scheme is a very small library with no external dependencies, intended for use as an extension and scripting language in C programs." ***terpri__ is now known as terpri
<terpri>hm, i hadn't thought about chibi for a while. maybe it would be useful for game developers, in contexts where they might embed lua or something <terpri>wren is interesting btw: https://wren.io/ not all that semantically interesting, but kind of like embeddable smalltalk with JS-ish syntax and erlang-style processes (iirc) <dsmith>I looked at Chibi slightly. Slow. Like Guile 1.4 slow. <dsmith>Now where is that scheme benchmark site? <ArneBab>yes, chibi is among the slow schemes ***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
***apteryx is now known as Guest47826
***apteryx_ is now known as apteryx
***wxie1 is now known as wxie
***nikita_ is now known as nikita
***nikita is now known as Guest25669
***Guest25669 is now known as nikita
***Guest6133 is now known as nikita`
<montxero>Are libraries defined using the `(library ...)` syntax restricted to one library per file? ***Server sets mode: +nt
<rlb>mwette: don't know if you were already thinking about it, but suggest considering providing msync as well, and maybe some way to get the fd for other operations, unless of course your api just works on file descriptors in the first place. <justin_smith>is there a way to get the "type" of some object without initializing goops? ***nckx is now known as ProboskissesXOXO
***ProboskissesXOXO is now known as nck
***nck is now known as nckx
<rlb>justin_smith: hmm, in what sense? class-of's in goops.c, and none of the class objects exist until it's loaded. And without that, I suspect you'd need to write your own equivalent dispatcher on pair?, integer?, char? ... that returns whatever kind of token you want. I (at least) don't know of anything similar outside goops. <justin_smith>rlb: I'm writing a bare bones multimethod / generic dispatch function, I want dispatch to be able to look at the type of a value, and the entire reason for doing this is to avoid the overhead of loading and using goops <rlb>On a somewhat related note, if it's not already true, it'd be nice if we had well specified way to get a goops class that can be used for specializations for record types, etc. <justin_smith>I can use the goops class-of if it doesn't require the other expensive redefinitions and overhead goops adds <rlb>i.e. other than (define <foo> (class-of (make-foo-instance))) <rlb>or maybe that's the recommended approach... <rlb>I'd have to think about it -- goops.scm expects to load that extension with (oop goops) as the current-module. <justin_smith>does the goops extension of primitives apply only to modules that import goops? if so I could compromise by making a wrapper module that re-exports class-of but not the rest of goops <justin_smith>but I really don't want to replace primitive stuff with the goops version throughout my vm <rlb>So even if it were safe for you to do it yourself just to get that function, you might break goops if you weren't careful. I would say that maybe you'd be better off to just duplicate what class-of is doing, for your own purposes, but then you'd have to track updates/changes, which might or might not be reasonable. <rlb>Is it the loading overhead that's too high I assume? <rlb>And/or could we improve that? <justin_smith>rlb: I had hoped that somewhere in the compiler / C code there was a hash map that knew about tag to type mappings, but I don't know guile's implementation well enough to know if such a thing would even be coherent <justin_smith>rlb: the loading part is minor, it is more that goops is replacing certain primitives with generics - or at least I thought I read it was doing that, I'd be happy to be proved wrong <mwette>rlb: got it : will look into msync() <rlb>e.g. if it turned out to be sensible, then maybe another option might be to move a smaller subset to (oop goops base) or something, including, at least, class-of, but don't know offhand, if that really *is* sensible, or if it's feasible wrt goops initialization. <justin_smith>I guess I'm used to typed vms where it wouldn't even make sense to have values without type tags, but hey a scheme vm could do other things in theory now that I think about it <rlb>mwette: not getting your msyncs right can cause really unpleasant bugs across platforms :) <justin_smith>rlb: in fact, for my usage, I could just use the type tag as a raw numeric value, as long as it maps cleanly to instances, if a type tag existed <rlb>(and you can't mix read/write and mmap ops portably without a good bit of care, if at all -- I forget whether we determined that you really have to close/reopen/seek when interleaving domains, or whether an msync/flush was sufficient) ***terpri_ is now known as terpri
<rlb>justin_smith: guile plays some fairly clever tricks with tagged pointers, so there's no single unified "type tag". <rlb>In exchange, fixnums are "free" as compared to say python, etc. <justin_smith>perhaps what I want is a dispatch with the various basic predicates (string? boolean? etc.) and finally get the record-type because non-primitives should be some sort of recrd... <mwette>rlb: thanks ; If I read you, open flags and mmap prot have to be consistent (e.g., O_RDONLY w/ PROT_READ) <rlb>Id' suggest looking at the implementation of class-of in goops.c if you haven't already, might help clarify some bits. <rlb>mwette: I think it may be worse than that. <rlb>But I forget what we encountered last time I was fighting with that across platforms. <mwette>civodul: I'm currently stuffing the mmap procedures into filesys.c. WDYT? <rlb>If I manage to find the info, I'll send it to you, but I'd suggest keeping with guile's general agnosticism there, if possible, and just "wrap posix(ish)" at your lowest level, so it's possible for people to help themselves. <rlb>i.e. so I can just call (foo fd FLAGS), etc. <rlb>and deal with the errno's myself, etc. <rlb>(But of course completely fine to have a higher level if there's a friendlier abstraction that makes sense most of the time (and we can determine is "sufficiently portable" wrt actual semantics.)) <rlb>justin_smith: I'm not positive, but I think that goops might not affect much in modules that don't import it, and many of its affects are on a per-function/method basis. <rlb>i.e. iirc, the primitive manipulation may mostly be "on demand", i.e. if you (define-method something-that's-currently-primitive ...) it gets promoted, but only in the current namespace. <rlb>You should be able to see that fairly easily. <justin_smith>rlb: yeah - I'll do some profiling, my current guess is that a module that imports goops for class-of and then re-exports should be safe perf wise (and it might even be safe to import only class-of from goops in each ns as well) <rlb>Try it, and then (write some-thing) from two modules, one where you made the specialization, and one where you didn't, I don't think the other module will be affected. <rlb>In which case, if you can get the init overhead of (use-modules ((oop goops) #:select (class-of)) to be low enough, which could benefit everyone if there are interesting improvements there, then you might be a lot happier relying on guile to maintain that function for you. <rlb>fwiw, that's what I've been doing in some bits I've worked on, i.e. just use class-of. <rlb>Oh, right wrt your comments above, #:selecting individual symbols from goops should be just fine. <justin_smith>cool - that would be the sane implementation, but I'm more than twice bitten expecting sanity in the past, even with lisps haha <justin_smith>thanks for the suggestions and insight, it's appreciated <rlb>Might also be preferable to use class-of for now, even if you might end up needing to do something different later. <rlb>(if you have other bits to wrestle first :) ) <mwette>right: I've working on implementing mmap w/ raw interface and in addition a simple "mmap-file". That latter could have a windows variant (i.e., MapViewOfFile). I have (provided? 'mmap-api) => #t; maybe (provided? 'mmap-file) is needed also. <civodul>mwette: filesys.c sounds like a good place ***sneek_ is now known as sneek
<civodul>looks like there's a renaissance of capabilities, no? ***slyfox_ is now known as slyfox