Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Irakli Gozalishvili
    @Gozala
    @egasimus in other words that line you pointed to is not really necessary
    but there to 1. information purposes 2. Make editor happy 3. I had a hope it would actually do import in a future.
    @egasimus I’m afraid I don’t remmebr all the details why I thought coupling with node’s require further was a bad idea. And you right currently you want platform to provide you with requier, although I had a plan to fix that & I think I wanted to make sure I would not introduce more dependncies that would prevent me from that.
    Irakli Gozalishvili
    @Gozala
    @egasimus oh there was also my ambition to make lua & go backends for wisp so coupling it with runtime forther did not seemed like a good idea. Now thinking about it, I would much rather have macro imports that depend on node’s require than no macro imports, I can deal with those constraints if I do actually get to work on those ideas.

    @Gozala I also imagine it should be easy to have an option to toggle including macros (and their dependencies) being included in the compiled output or not? This could be either a compiler option, or per-module and/or per-macro flag (via metadata)... I can certainly see how a Wisp library which is distributed in its compiled form would want to make its macros available without having to recompile the whole library every time

    That actually reminded me another idea I had, which was to generate two outputs when file with macro definitions was passed like module.js and module.macros.js so that macro definitions won’t tax the generated js, but would still make it available, alternative would be to let compiler either emit file with macros or file with actual js so you could create two outputs or one.

    @egasimus but more I though about it it felt that if library that wishes to export macros could just bundle wisp files and be done with all that.
    Adam Avramov
    @egasimus
    @Gozala been wondering about why this test fails: https://github.com/Gozala/wisp/blob/master/test/protocols.wisp#L16
    Does it perhaps expect to see Cannot call method 'apply' of undefined and fail because Node says Cannot read property 'apply' of undefined instead?
    Adam Avramov
    @egasimus
    @Gozala: Yet another question -- any particular reason for this? https://github.com/Gozala/wisp/blob/master/src/analyzer.wisp#L220
    A pattern I liked about ClojureScript was being able to declare exported symbols from withing a let binding using def. Is there anything in particular which makes this behavior unfeasible for Wisp?
    Adam Avramov
    @egasimus
    Ah, looking at the 11 failing tests, it seems that some protocol code relies on that behavior -- otherwise some locals get exported.
    Still, when you have the time, can you please spare a moment and let me know why you've decided to go with def used for declaring locals? :-)
    Irakli Gozalishvili
    @Gozala
    @egasimus analyzer at this poin isn’t smart enough to handle defsin let
    @egasimus that line is to avoid exporting every def regardless of where it’s run into
    @egasimus I’m not totally understanding a question, but if my guess is correct, then the reason is because making def export by default ended up exporting too much, but with some improvements to analyzer it actually could be advanced to export only things that needed to be.
    @egasimus I think if I was starting with this toady it would have being different, current state is just a reflection of how parser analyzer etc.. have evolved
    Adam Avramov
    @egasimus
    @Gozala I'm not sure how/why the analyzer can't handle defs in let. It would basically be equivalent to setting something in exports from withing a normal JS closure, wouldn't it? What I don't understand is what other purpose could def serve if you already have let
    Irakli Gozalishvili
    @Gozala
    @egasimus analyzer does not currently carries much info about the depth of the scope
    so if you have def with in a function you don’t wanna export that for example
    @egasimus and if I’m not mistaken let itself expands to series of def’s in wisp
    or at least used to
    @egasimus I’m afraid I can’t recall all the issues, but there were planty if def was treated as export by default.
    @egasimus not to say that can’t be fixed, it’s just yet another thing that would require some work
    @egasimus also to be honest I never felt the pain of not having def with-in let so I never bothered fixing it.
    Irakli Gozalishvili
    @Gozala
    @egasimus are you still interested in making macro imports ?
    @egasimus and if so can I help you with that ?
    Adam Avramov
    @egasimus
    I definitely am but I haven't quite started yet. :)
    Prashant Singh
    @prashtx
    @Gozala &co: wisp looks super cool. I finally got around to doing some hello-world-ish stuff in it the other day
    But I'm having some trouble with the repl, which is slowing my learning curve
    It looks like none of the standard functions/macros are present in the repl (wisp or wisp -i)
    So I get a ReferenceError: sum is not defined for (+ 1 1), for example
    ns also seems to be undefined, so I'm unable to bring functions into the namespace to use in the repl
    Irakli Gozalishvili
    @Gozala
    @prashtx ns should work and you should be able to import all of these using it
    @prashtx you can also play around with http://www.jeditoolkit.com/interactivate-wisp/
    Prashant Singh
    @prashtx
    @Gozala: hmm, just tried installing wisp on another machine, and it seems to work. Possibly an issue with node 0.12 (the machine where the repl didn't work)?
    also a quick note: I was unable to import references from the wisp.sequence namespace when I was running from a random directory with globally-installed wisp
    but when i made a new dir and installed with npm install wisp, it worked out (still running repl via globally-installed)
    Irakli Gozalishvili
    @Gozala
    @prashtx that’s strange, would you mind submitting a bugs for those & I’ll try to look into that
    @prashtx or if you wann try to track down it’s even better
    @pirosikick BTW ns will be undefined as it’s a macro so that could have confused you as well
    Prashant Singh
    @prashtx
    the undefined did confuse me, but I had tried copying and pasting a working namespace import from a working .wisp file
    If I get a chance, I'll try tracking it down, otherwise will definitely file a bug
    Murphy Randle
    @splodingsocks
    HI there! Just wondering, is anyone actively developing this project?
    Or actively using it
    Adam Avramov
    @egasimus
    @murphyrandle I am using it for a personal project; I am also continually looking forward to contributing to its development, but so far Wisp has proven very usable in its current state -- and there hasn't been anything I've needed to fix in the language other than an outdated entry point (Gozala/wisp#118). If there's anything in particular you'd like to know, I'll be happy to help.
    Murphy Randle
    @splodingsocks
    that's good to know, @egasimus! Have you been using it for long?
    Adam Avramov
    @egasimus
    @murphyrandle Since about February maybe.
    Murphy Randle
    @splodingsocks
    Okay, cool.
    Daniel
    @danieltanfh95
    is there a way to import local namespaces into other modules?
    Max Gonzih
    @Gonzih
    hello guys, what is the way to use macroexpand-1?