<seepel>Hello guile, I've been hacking on the ecmascript implementation a bit and I'm wondering if I should try to merge my changes upstream. If so, is there somewhere I should look for instructions on how to do so? I read the section on the home page about contributing a bug fix, but I haven't contributed before and still have some doubts about how exactly I would go about it. <rlb>seepel: I'm not positive, but I think maybe you can post the patches to guile-devel@gnu.org for review if they're not giant (and maybe even if they are?). That said, if you want to check back here when civodul is handy (generally earlier), he should be more qualified to answer. <seepel>rlb: Thanks, I was wondering if guile-devel might be the place but wasn't sure. When you say earlier, do you have a suggestion how much earlier? Like which timezone? I guess the other question I have is if multiple commits is better or one big commit. And if the git-send-email defaults are good. I have things broken up into four commits, probably a few hundred changed lines total. <rlb>I think generally European-ish, maybe? <rlb>And, I'd assume git-send-email is fine. <rlb>You can also ask sneek to ask :) <rlb>i.e. /msg sneek help, and I think the command may be "later tell civodul ..." or something. <leoprikler>As far as commits goes, it should be fine if each commit makes a logical change, e.g. changing one function, adding one function, etc. <leoprikler>While it is possible to split things up too far, I don't think that's what you've meant when you ask the question. <rlb>seepel: and for the final version, I think the convention will probably include the changelog style entries you can see in the git history (in the commit meesages). I think there may have been some contemplation of eventually automating that, but not sure. <rlb>But perhaps get the code itself settled first? :) <leoprikler>Either way, the worst that can happen is someone pointing out your guideline violation (*gasp*), perhaps even fixing the issue for you if it's something minor. <seepel>No, I think each commit is pretty logical, one fixes function prototypes, one adds try/catch, etc. When I sent myself the changes it sent them each as a separate email, so I wasn't so sure. Looking through the archive I didn't really see many examples of multiple commits. <rlb>--annotate --cover-letter can be useful too (you may already know) <rlb>If you want to add an overall summary, etc. <seepel>I do not, I'm pretty new to git through email, but that is exactly what I'd like to do. <rlb>So that will open EDITOR for each commit, and a "cover letter" mail, and it'll thread them all (email-wise). <rlb>You can put your own comments (asides, whatever) in the section after the commit message and before the --. And of course edit the Subject: of the cover letter to be a suitable overview. <rlb>Also, if you get cold-feet, you can just hit C-c in the terminal where you ran send-email to cancel the process. *rlb recommends EDITOR=emacsclient for all that, and then it's "C-x #" to finish editing and go to the next mail. <seepel>I'm the one crazy lisper that can't quit his vim habit... <rlb>Heh - evil-mode, spacemacs (no experience) or...? <rlb>emacsclient and --daemon mode can definitely help with the startup time issue that some vi users (understandably) have. <seepel>I keep trying, but it never seems to jive quite right. And that is saying something, because it is truly more painful to do this stuff in vim. <rlb>Yeah, plenty of things in emacs I'd find it very hard to give up, but I can sympathize. And happy to help if I can, but also imagine I'm reasonably well off topic :) <seepel>I've scratched the surface with fugitive, but haven't managed to really dig in quite yet. <justin_smith>fwiw I used emacs for over a decade, and am quite happy with neovim today <seepel>I still use vim mainly because I can ctrl-w directly out of a terminal, though neovim has a reasonable repl plugin that I miss. <seepel>I was also wondering how the FSF copywrite assignment would go, I'm assuming I probably wrote just enough code that I'd need to do that. <seepel>I did see that, but wasn't sure about the process. In other words, what will I need to do in order to assign copyright? <justin_smith>aha, there's one form that assigns copyright for future work on the same project <rlb>Generally, you just mail them your form, and then they'll have it on file, and "that's it". <rlb>They might have other options, but regular post is what I've used. <seepel>Ahh, yeah, this looks like what I was curious about. <refcfar><dsmith-work "I think old interpreted guile us"> In the Guile manual, in the section "Source Properties" it reads: <refcfar>Shouldn't it then be possible to reconstruct the source expression? It doesn't have to be exactly as originally defined, but being able to read the definition would be useful regardless <refcfar>Err, I mean it could then retrieve the source expression from said location <refcfar>And even if not, can't an S-expression be constructed (decompiled) so as to give at least something even if not always very readable? ***rubdos_ is now known as rubdos
<leoprikler>But there seems to be no decompiler from bytecode <refcfar>Is there a quick and standard way to just use/import a file that isn't really a module? Something like `(use-file "./my-script.scm")`? <refcfar>`(load-from-path "./my-script.scm")` <leoprikler>load-from-path, but if you use "./some-path.scm" in a script, you might even want plain load instead <leoprikler>alternatively, you can determine the path of the current script as (dirname (current-filename)) and then use (load (string-join %dir "/my-script.scm")) <leoprikler>either way, you're throwing a compilation, that isn't auto out of the window, which might not be what you want for library use <refcfar>What about simply parsing a file as syntax or quoted? <refcfar>I realised that I'm not really looking to load but rather just read from it. I see that I can open a stream from input but there are a lot of extra steps just to parse it as a sequence of S-exprs <mwette>refcfar: I have done that. I use a loop to read one sexp at a time. Check out Guile's 'read' procedure <refcfar>mwette: I was thinking of wrapping the file contents in "(list " ")" or something and then I thought I had found a string->s-expr but now I appear to have lost track of it <mwette>You can also just (define form '(<file contents>)) and then load <refcfar>Yeah the tricky part is converting the string to s-expr <mwette>refcfar: (with-input-from-file filename (lambda () (let loop ((forms '()) (form (read))) (if (eof-object? form) (reverse forms) (loop (cons form forms) (read)))))) <seepel>refcfar: You can use the read procedure to read an s-expression from a port (read (open-input-string "(foo bar baz)")) => (foo bar baz) <mwette>^ above will return a list of the forms in file with name filename <refcfar><mwette "sudoreboot: (with-input-from-fil"> Huh.. I wouldn't have expected `read` to do.. whatever it is it's doing there <refcfar>It's reading a single character at a time and somehow producing single-char s-exprs that, by `cons`ing into a list creates a complete s-expr? <refcfar>Each `(read)` invocation takes a newline-terminated s-expr? <refcfar>No, not newline, just a single s-expr <refcfar>I did wonder when I tried using `read` and only got one expression rather than the entire content of the file but I didn't think you could read several times and get different results <refcfar>Anyway, it all makes sense to me now <refcfar>Using that expression you gave + `pretty-print` I have a basic auto-formatter. Heh. ***civodul` is now known as civodul
<leoprikler>refcfar: `read` and other functions forward the position of the port they read, so at the next time they're invoked, that'll be different <leoprikler>hence why looping `read` until you get #<eof> gets you all s-exprs in a file, string, you-name-it <refcfar>Yeah I figured it out after thinking about it