All the things you wanna see in the spork

[pepe]

What kind of functionality would you like to see in the spork utility library? Bonus if the code exists in present libraries.

My list:

• URI parser - https://github.com/andrewchambers/janet-uri
• HTTPD- https://github.com/joy-framework/halo2
• DateTime - ala https://github.com/subsetpark/janet-dtgb
• Temple - https://git.sr.ht/~bakpakin/temple
• cond-> - do not know about the implementation

Gathered:

• A project.janet loader (as discussed in project.janet can't be eval'ed without access to functions defined in the jpm script #601)
• A set of extra error helpers
• Some form of globals
• CSV
• A cross platform base64 encode/decode
• Topological sort and recursively walking directory trees
• TOML
• UTF-8 utility functions (perhaps wrapping utf8.h
• Combinatronics functions (similar to those found in Clojure's math.combinatronics)
• GCD and LCM functions (similar to those found in Clojure's math.numeric-tower)
• jdn tooling

Per janet-lang/spork#26 (comment), the spork is gonna stay Janet only, at least for the foreseeable future.

[pyrmont]

• A project.janet loader (as discussed in project.janet can't be eval'ed without access to functions defined in the jpm script #601).

[yumaikas]

So, I don't have this in at all a mature form yet, but a set of extra error helpers would be nice: https://github.com/yumaikas/anno-server/blob/main/errs.janet is a personal start.

Also, some form of globals https://github.com/yumaikas/janet-globals would be nice to have in spork.

[yumaikas]

So, I've since extracted those error helpers into their own library, here: https://github.com/yumaikas/janet-errs

Right now, the readme is still lacking, and I'm unsure how many more helpers one might want to add, but I think they're going in a good direction.

[uvtc]

Maybe csv.

Has path been officially moved into spork?

I tend to like installing modules separately, as needed, though I understand the convenience of getting everything via one single jpm install spork. Are they easier to maintain if they're all in one repo?

[pepe]

CSV is good idea.

Indeed path was moved into spork. Convenience is the key here, yes.

I am not sure what plans are for the standalone library, but it will probably be in spork where will be any development.

@bakpakin stated that Janet is well equipped to use big libraries cause the only code reachable in the compilation phase is in the resulting image. But as always, I could have totally butchered the meaning. This is my understanding, though.

[bakpakin]

@pepe is correct, there is very little cost to using "big" libraries in Janet, and most of our "big" libraries are actually quite tiny.

It makes versioning much easier as well, and my own personal experience speaks to the fact that one repository is much easier to maintain than many small repository up until a certain size. That size is much, much larger than spork.

This is mostly opinion, but the javascript trend for micro modules is terrible imo, I would hope people had learned from leftpad. JS adopted the micro module approach initially due to technical limitations of JS, not because it is a better way to organize source code.

There are some other benefits, like spork submodules can easily depend on other spork submodules without worrying about maintaining dependencies.

[pepe]

A case for Temple:

• It is a simple one file module
• It contains many examples of some of the more advanced techniques with Janet
• Templating is a great tool for the wider standard library

[pepe]

What do you think, @bakpakin? Is it reasonable? I will happily move code and create PR.

[yumaikas]

Also, a cross platform base64 encode/decode would be good to have (perhaps along with some other encoding/conversion functions). Right now the only source I can find for doing this in janet is @swlkr's codec module, at https://github.com/joy-framework/codec, where it's bundled with some other crypto functions. Right now it doesn't compile on Windows.

[yumaikas]

Also, topological sort and recursively walking directory trees would be nice additions as well

[sogaiu]

With respect to walking a directory recursively, I remember seeing more than one attempt. Looking through some of the repository lists in #563 (comment) , one thing that came up was around: https://github.com/jeannekamikaze/janet-filesystem/blob/master/filesystem.janet#L29

There might be others too.

Update: It looks like I didn't paste the link I had in mind -- sorry if that resulted in confusion. Hopefully that has been addressed.

[yumaikas]

Right now it's something that I, @subsetpark and probably more people have written. There are quite a few examples out there

[uvtc]

A recent thread here reminded me that a TOML parser would be handy to have.

[pyrmont]

You mean moving Tomlin into Spork? Or writing something similar?

[uvtc]

Yes, I was suggesting moving Tomlin into Spork.

Currently, it seems that spork is all one-file modules, but if it's to be a "batteries included" standard-ish library, then I think it would need to support modules that have enough parts to need their own directory within spork.

[pyrmont]

Some additional suggestions:

• UTF-8 utility functions (perhaps wrapping utf8.h)
• Combinatronics functions (similar to those found in Clojure's math.combinatronics)
• GCD and LCM functions (similar to those found in Clojure's math.numeric-tower)

Is Spork intended to only be written in Janet? Would you include things that wrap C libraries (such as the aforementioned utf8.h)?

[pepe]

The question of Janet only is open, I guess. But it seems to me that high-quality cross platform C code could be OK.

[pepe]

So at least for now, let's make spork Janet only per janet-lang/spork#26 (comment)

[yumaikas]

Another thing that would make sense to have in spork: Some cross-platform wrappers around os/spawn to make things like piplines easier to express. #592 <- This issue covers a start on the sort of code that'd need to be written.

I also think that eventually we'll need to do a bit of traige and/or prioritization on this might be in order? I suppose people are welcome to create PRs for these libraries as they become relevant, and some of then (like the errs library I'm suggesting), might be a while before they are ready for inclusion in spork.

[pepe]

This is to know what people think. No obligation arises about what will and will not end up in the spork.

BTW, yesterday I have coded around the os/spawn without any big problem. Maybe it is that cross-platform I missed.

[yumaikas]

Eh, I'm just meaning some sort of api like this:

(spork/os/pipe 
    (os/spawn ["exe" "arg1"] :p { :out :pipe })
    (os/spawn ["exe" "arg1"] :p { :in :pipe :out :pipe })
)

And then automagically have it a) give you a way to wait for all of the processes to close or to b) read from the last process in the pipeline. Maybe add some sort of (spork/os/tee ) call, to allow inspecting the middle of a pipeline?

[MikeBeller]

JDN is used in several packages. It's a very small library by @andrewchambers. Not sure how he would feel but it seems to me a good candidate for spork.

[uvtc]

My understanding was that jdn was "Janet Data Notation", or a way to pretty-print Janet data structures, for example:

(printf "%j" x)

Can you provide a link to Andrew's jdn library? What does that library do?

[MikeBeller]

Oh sure -- https://github.com/andrewchambers/janet-jdn
Just makes it easy (or "standard") to use JDN.

[andrewchambers]

I think now the core library has some helper functions that makes this package less useful.

[MikeBeller]

Ah. What are those functions in the core? ( I just added jdn package to something I was working on. :-) )

[andrewchambers]

I think just 'parse

[MikeBeller]

Ah yes. Looks like 'parse is very similar to jdn/decode. And encode is just a printf %j so...I guess I should replace my use of this module with those, to keep it simple. Thanks.

…

On Fri, Feb 5, 2021 at 6:35 PM andrewchambers ***@***.***> wrote: I think just 'parse — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#597 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM7HKUNEF47BU3CEGRRBPDS5R6EBANCNFSM4WJCSKUA> .