<marler8997>
if you're on a platform where a socket is a file descripts, then you want to be able to pass socket_t to functions that accept fd_t
<marler8997>
it's platform dependent, just like the APIs
<marler8997>
the fact that socket_t is an fd_t is important for the type system to know
<marler8997>
well, that's kinda why we have socket_t and/or fd_t
<marler8997>
how to do?
<marler8997>
and I want to pass my array to a function that accepts an array of file descriptors
<marler8997>
I have an array of Socket
<marler8997>
why?
<marler8997>
and an array of file descriptors?
<marler8997>
cast?
<marler8997>
how would you expect people to pass a Socket to a function that accepts a file descriptor?
<marler8997>
are you saying we should remove socket_t?
<marler8997>
when would someone use Socket vs socket_t?
<marler8997>
*cast
<marler8997>
so if they pass an array of Socket to a function, then it can be case to an array of file descriptors?
<marler8997>
So on linux, can the user assume that Socket is just a handle?
<marler8997>
on windows they are Handles
<marler8997>
some API's actually take an array of socket handles, how would that work?
<marler8997>
so, will there be a Socket.asFileDescriptor() or something?
<marler8997>
The fact that a socket is a handle/file descriptor is required knowledge to use it with certain APIS, such as select/epoll/kqueue/IOChannels
<marler8997>
I added socket_t :)
<marler8997>
is it that you're saying socket_t is a socket handle for platforms that support such a thing, and Socket is a socket object that may or may not be a handle, it could be anything?
<marler8997>
you could replace socket_t with anything as well right?
<marler8997>
isn't socket_t just as opaque as Socket?
<marler8997>
TheLemonMan, why a Socket struct instead of using os.socket_t directly?
2021-03-19
<marler8997>
yeah I would expect "try EXPR" to unwrap an error the same way regardless of whether it's a value or a function call
<marler8997>
yeah I actually think Python is great for the space it's in. However, there seems to be a space where sometime Python is a bit overkill, when you just want to call other programs and "stitch" them together. That's what BASH is for and now stitch as well
<ifreund>
companion_cube: marler8997's, I'm responsible for bouncing some ideas
<FireFox317>
if marler8997 isn't here, i'm currently on windows too
<TheLemonMan>
marler8997, I think I fixed the problem with the terminal clearing, give it a spin when you have some time
2021-03-11
<earnestly>
They left before marler8997's comment about getting one
<marler8997>
gofundme to get LemonBoy a windows machine :)
<andrewrk>
marler8997, run the std lib tests while resizing the terminal chaotically
<marler8997>
TheLemonMan, what's an easy way to test your change?
<marler8997>
I'll see if I can get to it soon then
<marler8997>
lol
<andrewrk>
marler8997, if you tell me it works fine on windows I'm going to spank that merge button straight away
<marler8997>
I'm literally going to do that now
<marler8997>
do you actually do that?
<marler8997>
that's a freakin awesome idea
<TheLemonMan>
marler8997, I've just learned that sticking post-it notes all around your screen is the best way to avoid forgetting stuff
<marler8997>
*bit
<marler8997>
yeah I give it a spin in a big, if I don't forget :)
<marler8997>
of course, always have been
<marler8997>
hey
<TheLemonMan>
marler8997, ping
<marler8997>
wth, how do these new features get in and I have no idea about them ?
<marler8997>
zig_version..??.??
2021-03-09
<marler8997>
yeah, would love to get people's feedback, let me know on #stitch
<marler8997>
I'm also fine with using a builtin commands for managing environment variables: @setenv "foo bar" "hey" (@env "foo bar")
<marler8997>
this python program: import os;import subprocess;os.environ["foo bar"] = "hey";subprocess.call(["env"])
<marler8997>
looks like it works
<marler8997>
right, but in the varname
<marler8997>
well, that's just BASH
<marler8997>
doesn't look like it: 'FOO BAR=what' env
<marler8997>
do OS's let you do that?
<marler8997>
TheLemonMan, good question
<marler8997>
access with $env.FOO
<marler8997>
env.FOO = bar?
<marler8997>
script variables use leading $
<marler8997>
follow up question, how would you want to differentiate between setting a script variable vs an environment variable?
<marler8997>
TheLemonMan, definite yes to that
<marler8997>
Fellow language connoisseurs, I want to get people's opinion on whether my stitch scripting language should add special syntax for variable assignment "foo = bar" of if I should use a builtin like "@set foo bar". Feel free to share your thoughts with me on the #stitch channel
2021-03-06
<marler8997>
which says nothing about the API, the api could be great
<marler8997>
Data Oriented Design
<marler8997>
hmmm, not sure it looks very DOD
<marler8997>
it's a pretty cool project, regex in like 500 lines of C code
<marler8997>
being inspired by Andrew's big DOD change, I found the opportunity to use the same technique to improve this tiny-regex-c library: https://github.com/kokke/tiny-regex-c/pull/62
2021-03-05
<andrewrk>
mikdusan, marler8997: -MM support turned out to be an easy fix. zig cc with jemalloc "just works" now
<marler8997>
ah
<andrewrk>
marler8997, <spoiler warning> we do eventually find the problem, a bug/missing feature of zig cc to support -MM
<marler8997>
It's got to be environment variables right? Is the makefile setting LD or something?
<marler8997>
where the make is failing but the command is not
<marler8997>
I'm at 30 minutes into Andrew/Loris pair programming stream
<marler8997>
bash has so many features and so much syntax, it's like the opposite of Zig in alot of ways
<marler8997>
but you're put it into nice modular functions
<marler8997>
lol, fair point
<marler8997>
600 lines is nothing
<marler8997>
braket this looks like a perfect example I can port
<braket>
marler8997: shameless plug if ya want: https://github.com/bl0nd/chive. It lets you swap out file contents without having to mark up the original file. I use it mainly to change app colors but you can swap out any section of a file.
<andrewrk>
marler8997, I don't have a working implementation, but I want one that notifies me when a long running command finishes
<marler8997>
fyi, I'm in the market for BASH/SHELL scripts I can port to my new stitch langauge for testing and guiding the feature design. Let me know if you have anything you think would be useful
2021-03-02
<marler8997>
not for me no, it did with iguana
<marler8997>
this reminds me of the iguana error, like there are extra characters around the data
<marler8997>
good test
<g-w1>
marler8997: https://clbin.com/p4Dd1 <- here is the error for the openssl with https://google.com but its not openssl static; the same thing triggers with regular openssl so I assume its a different bug; so I say ship it!
2021-03-01
<marler8997>
g-w1, hey have you tried looking at that opensslstatic issue? I don't want to deploy binaries until we figure out why it isn't working on your machine
2021-02-28
<marler8997>
let's do it
<marler8997>
this is the second time we've taken over the Zig channel, it might be time for that as at some point too much discussion is probably rude
<marler8997>
I'm going to create an issue in the repo and enumerate them
<marler8997>
ok, I think at this point we need to write down the options and come back to this
<marler8997>
How often do we think someone will use >...<?
<marler8997>
I mean @eq...
<marler8997>
$eq $lt $gt are the plan at the moment
<marler8997>
those are not planned right now though
<marler8997>
true
<marler8997>
more reserved characters
<marler8997>
@>>hello this is a coo! string with <xml> tags and stitch @>strings< as well<<
<marler8997>
"..." and @>>>...<<<
<marler8997>
there's that one too
<marler8997>
@>>><<<
<marler8997>
oh right
<marler8997>
how is @```...``` different from @"""..."""?
<marler8997>
we could go back to "..." and @"X...X
<marler8997>
but compare that to "..." and @"""..."""
<marler8997>
so we could solve all the issues with ><
<marler8997>
say we did that, what would you think about multiline?
<marler8997>
so we only need ><
<marler8997>
oh right
<marler8997>
we have 2 methods, increasing delimiter count, or custom delimiters
<marler8997>
ok, so the current idea is "..." and >>>...<<<
<marler8997>
I see now
<marler8997>
oh I see, you keep going while you see <
<marler8997>
huh?
<marler8997>
yeah, can't end strings with <
<marler8997>
oh that wouldn't work
<marler8997>
>>my stitch string >hello<<<
<marler8997>
>>my <xml> tag<<
<marler8997>
>hello<
<marler8997>
>hello ! this is a "string" with all sorts of character<
<marler8997>
with no way to escape the double-quote
<marler8997>
I think supporting double quote "..." is probably the right way to go, so I think we can simplify and assume that one
<marler8997>
yeah it has a certain look to it that's appealing
<marler8997>
so may ways!!
<marler8997>
interesting
<marler8997>
because @%X...X would be alot more rare
<marler8997>
If we suppsed "...", then using something like @%X...X seems more tractable than without "..."
<marler8997>
yeah that seems odd
<marler8997>
or the other way? @"..." """"....""""
<marler8997>
So maybe "..." and @""""....""""
<marler8997>
yeah, we might be able to do better
<marler8997>
or (@echo)
<marler8997>
@emptystring :)
<marler8997>
"""this is a string"""
<marler8997>
I could do the same with just double quotes right?
<marler8997>
so it would be "this is a string" or @`this is a "string" that can use double quotes`
<marler8997>
one big reason is that " almost always a special character, and people will expect it to be
<marler8997>
I'm very tempted to just allow "..."
<marler8997>
not bad
<marler8997>
I think I'll switch to that for now, and make a note about kakoune's syntax to consider
<marler8997>
single-quote could be the default conventional delimiter
<marler8997>
@''hello'
<marler8997>
If we didn't add any special characters, what about @' to start a delimited raw string?
<marler8997>
by that I mean, end the delimited string and tak on more
<marler8997>
you could still do %"hello "@"Joe@"
<marler8997>
I'm thinking if have to esacpe your delimiter, just use a different delimiter
<marler8997>
right
<marler8997>
interesting idea, but it kinda defeats the purpose of the delimited string, that its a WYSIWYG string
<marler8997>
oh, and if the closing delimiter is double it's considered apart of the string
<marler8997>
yeah I like it actually
<marler8997>
found kakoune pleasent to use?
<marler8997>
If I were to use the same, I'd be adding 3 special characters, ', " and %
<marler8997>
that's pretty cool
<marler8997>
@@"..." looks farily clean, @$"..." looks a bit uglier to me, and @@"..." is easy to type
<marler8997>
Yeah I wasn't sure what would be a good character for delimited string literals
<ifreund>
marler8997: is this a typo? it seems to me that escaping with @@ would be more intuitive...
2021-02-27
<marler8997>
I've pushed the fix to master, update and try again
<marler8997>
that's pretty cool Zig was able to find that bug :)
<marler8997>
should be *openssl.FILE, now I can build with x86_64-linux-musl
<marler8997>
and they can have different entries for package of the same name correct?
<marler8997>
andrewrk, I noticed that you can't set a sub-sub package with the same name to different modules, is this an intentional restriction or an oversight?
<marler8997>
yeah I had started one, but then stopped because I realized we would need a static exe for that
<marler8997>
I should try on a few other machines and see if it works
<marler8997>
NixOS
<marler8997>
g-w1, it works for me so we'll have to figure out what's going wrong with yours
<marler8997>
andrewrk, I have to call the openssl config and make file to generate a few files, so will need perl and make and so on at the moment for windows
<andrewrk>
marler8997, nice does that make it work on windows now too?
<marler8997>
g-w1, zigup working with opensslstatic, just pushed to master
<marler8997>
yeah I agree, after I played with it on some code it was more readable and I think it helps to immediately see whether a symbol is defined by the language or the user
<ifreund>
marler8997: cool, I think it will be a net positive for cognative load despite bringing stitch up to 5 special symbols :)
<marler8997>
I'm saying I may not be calling the right function to get the error, or calling it the right way
<marler8997>
and/or, if the error is getting retrieved correctly
<marler8997>
right, but I'm not sure error code 5 is the info we need
<marler8997>
ifreund, I'm making the change to @ for reserved. I like it
<marler8997>
might need to check openssl/ssl.zig to see if the error reporting is accurate, I'm no openssl expert :)
<marler8997>
the build code for either actually has no shared code, but the zig module is exactly the same for both
<marler8997>
-Dopensslstatic of course :)
<marler8997>
ah, that's true
<ifreund>
marler8997: isn't $@ leaking a builtin type thing into the non-reserved namespace? @$|delimited| would make more sense IMO
<marler8997>
but my machine is pretty baller :)
<marler8997>
takes 7.4 seconds on my machine
<marler8997>
g-w1, try it out for yourself :) haven't tried it with zigup yet
<marler8997>
I think that makes intuitive sense
<marler8997>
I could use @"foo" for the shorthand, $@|delimited| for the delimited
<g-w1>
marler8997: nice, how long does it take to build, and did you get it with zigup yet?
<marler8997>
I'm updating my docs based on our conversation as we speak
<marler8997>
ok I'll remember that
<marler8997>
this mean making double-quote a special character
<marler8997>
and "foo" is still on the table
<marler8997>
I've also considered shorthand, $"foo", which would also mean @"foo"
<marler8997>
could go either way, either $@"foo" or @@"foo"
<marler8997>
I need to change the name of that
<marler8997>
that's a delimited string literal
<marler8997>
I forgot
<marler8997>
sorry
<marler8997>
oh wait hold on
<marler8997>
dollar doesn't recognize and @ symbol for anything
<marler8997>
$@ would be a syntax error
<marler8997>
keeping them limited is good, but not if it sacrifices too much readability
<marler8997>
I've started by limiting myself to only a few reserved characters, currently there are only 4: $, #, ( and )
<marler8997>
if that's the case then I will probably use it
<marler8997>
you might be right
<marler8997>
and $ for user-defined things
<marler8997>
make @ be for all reserved things
<marler8997>
that is an interesting idea
<marler8997>
you'd have to call it like (@scriptfile)
<marler8997>
I could make that a program though
<marler8997>
yes, like $scriptfile
<marler8997>
right now it's "g" for "global", so $g.echo
<marler8997>
there is a special scope that allows you to set/retreive user-defined symbols that conflict with reserved symbols
<marler8997>
$echo still points to the builtin
<marler8997>
however
<marler8997>
yes
<marler8997>
as I went on I found that adding a few types made a few things alot simpler
<marler8997>
I started with everything being text
<marler8997>
you're giving me ideas on how to better document this :)
<marler8997>
String, Bool, Builtin, CommandResult
<marler8997>
there's a handful of Object type in stitch so far
<marler8997>
$echo is a Builtin object
<marler8997>
of course, the builtin programs are just implemented as internal functions in the interpreter, but from the perspective of a stitch script they behave exactly the same
<marler8997>
everything is program, no functions (haven't found a need for them yet)
<marler8997>
yes
<marler8997>
then, $myotherscript would call that script
<marler8997>
and maybe I could support this: $set myotherscript $load myotherscript
<marler8997>
right now you can do this: $call myotherscript ...
<marler8997>
a builtin is just like any other program
<marler8997>
@foo vs $foo (@foo is a builtin, $foo is a variable)
<marler8997>
so you'd like to namespace different types of variables with a different symbol
<marler8997>
$echo is a variable that returns a Builtin object
<marler8997>
these keywords are actually just variables as well