ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
kristate has joined #zig
mal``` has joined #zig
kristate has quit [Ping timeout: 255 seconds]
Aequus has quit [Ping timeout: 264 seconds]
mal`` has quit [Ping timeout: 264 seconds]
Tobba has quit [*.net *.split]
andrewrk has quit [*.net *.split]
pqflx3[m] has quit [Ping timeout: 245 seconds]
lorde_kumamon[m] has quit [Ping timeout: 256 seconds]
clebermatheus[m] has quit [Ping timeout: 260 seconds]
dtz has quit [Ping timeout: 260 seconds]
kammd[m] has quit [Ping timeout: 256 seconds]
Triplefox[m] has quit [Ping timeout: 260 seconds]
bb010g has quit [Ping timeout: 256 seconds]
sg-james[m] has quit [Ping timeout: 276 seconds]
Tobba has joined #zig
andrewrk has joined #zig
allan0 has quit [Ping timeout: 240 seconds]
kristate has joined #zig
donlzx has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
pqflx3[m] has joined #zig
hryx has joined #zig
kristate has quit [Remote host closed the connection]
quc has quit [Ping timeout: 260 seconds]
quc has joined #zig
kammd[m] has joined #zig
bb010g[m] has joined #zig
dtz[m] has joined #zig
LordeKumamon[m] has joined #zig
sg-james[m] has joined #zig
davr0s has joined #zig
kristate_ has joined #zig
Triplefox[m] has joined #zig
clebermatheus[m] has joined #zig
kristate_ has quit [Remote host closed the connection]
isd has joined #zig
donlzx has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kristate has joined #zig
darithorn has joined #zig
kristate has quit [Ping timeout: 260 seconds]
kristate has joined #zig
hryx has quit [Ping timeout: 252 seconds]
dbandstra has joined #zig
kristate has quit [Ping timeout: 276 seconds]
kristate has joined #zig
kristate has quit [Ping timeout: 256 seconds]
zolk3ri has quit [Quit: leaving]
v1zix has joined #zig
<andrewrk>
tiehuis, what's the way to port the logic of function using std.math.big.Int? bool bigint_fits_in_bits(const BigInt *bn, size_t bit_count, bool is_signed);
<andrewrk>
I'm guessing I should use sizeInBase(2) and then make sure it's positive for unsigned types?
<andrewrk>
or maybe bitcount()
<dbandstra>
andrewrk, just to follow up a bit on the comment about comparing a nullable to a non-nullable... it would be ergonomic to be able to compare two things that would be comparable if they weren't optional (ints, floats, etc). nullable types are kind of like boxes in zig, but not completely (`some_nullable_int = 5` doesn't require boxing syntax), so it would be in line with that
<andrewrk>
it is different than == or != on nullable pointers though
<andrewrk>
for example for a ?i32 it would be 2 operations vs ?*i32 it would be 1 operation
<dbandstra>
is that bad?
<andrewrk>
it might be ok
<andrewrk>
I think it's worth a proposal issue
<dbandstra>
ok, i'll try to put one together at some point
darithorn has quit [Quit: WeeChat 1.9.1]
<dbandstra>
`const x = func() orelse return;` or `const x = func() orelse continue;` is an interesting feature
<dbandstra>
one of the most bizarre things coming from c :p
<andrewrk>
it seems like that's what you naturally end up with if you consider how the noreturn type works
<dbandstra>
yeah
<dbandstra>
i've worked in languages with a 'never' type but they didn't support this
<dbandstra>
probably because it was typescript being restricted by js compatibility
<dbandstra>
while i'm on the topic of breaking free of c/js/ts, switch statements as expressions is sooo nice
<andrewrk>
agreed
<dbandstra>
it's such a pleasant feeling every time i'm working on something and realize i can use it
<dbandstra>
haven't been following this but it looks like stage2 built its first program?
<andrewrk>
that's right! its first program with a successful exit code
<dbandstra>
congrats :D
<andrewrk>
this means we can start having stage2 tests
<dbandstra>
1 passing, 10 or 20 thousand to go?
qazo has joined #zig
<andrewrk>
I type fast ;)
<GitHub129>
[zig] andrewrk opened pull request #1266: Self hosted libc hello world (master...self-hosted-libc-hello-world) https://git.io/fNcxG
isd has quit [Ping timeout: 256 seconds]
isd has joined #zig
isd has quit [Ping timeout: 256 seconds]
davr0s has joined #zig
v1zix has quit [Ping timeout: 252 seconds]
allan0 has joined #zig
MajorLag2 has joined #zig
MajorLag1 has quit [Ping timeout: 276 seconds]
dvn has quit [Ping timeout: 276 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
JinShil has joined #zig
davr0s has joined #zig
dbandstra has quit [Quit: Leaving]
very-mediocre has joined #zig
skyfex has joined #zig
very-mediocre has quit [Ping timeout: 252 seconds]
stratact has quit [Quit: Leaving]
Tobba has quit [Ping timeout: 264 seconds]
JinShil has quit [Quit: Leaving]
tracernz has joined #zig
zolk3ri has joined #zig
Triplefox[m] has quit [Remote host closed the connection]
kammd[m] has quit [Remote host closed the connection]
bb010g[m] has quit [Read error: Connection reset by peer]
dtz[m] has quit [Remote host closed the connection]
pqflx3[m] has quit [Remote host closed the connection]
sg-james[m] has quit [Remote host closed the connection]
clebermatheus[m] has quit [Remote host closed the connection]
LordeKumamon[m] has quit [Remote host closed the connection]
pqflx3[m] has joined #zig
dvn has joined #zig
qazo has quit [Quit: Page closed]
qazo has joined #zig
dtz[m] has joined #zig
sg-james[m] has joined #zig
LordeKumamon[m] has joined #zig
bb010g[m] has joined #zig
kammd[m] has joined #zig
Triplefox[m] has joined #zig
clebermatheus[m] has joined #zig
very-mediocre has joined #zig
zag has joined #zig
zag has quit [Client Quit]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mal``` has quit [Quit: Leaving]
mal`` has joined #zig
davr0s has joined #zig
Tobba has joined #zig
qazo has quit [Ping timeout: 252 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<winksaville>
So stage3 will be able to be used to create compilers without previous stages using llvm c interface. But for zig the other key apparently is compiling compiler-rt, what is special about compiling compler-rt?
<andrewrk>
it's a dependency of llvm-generated .o files
<andrewrk>
so you need it built for the target
davr0s has joined #zig
Hejsil has joined #zig
<Hejsil>
We have way too may words for "interface".
<winksaville>
hmmm, is it correct that only stage1 can compile std/special/compiler-rt/* files or is it some other reason a stage1 compiler is required?
<winksaville>
(I'm trying to understand what is stage1 able to do that stage3 can't and thus requires stage 1/2 to be maintained moving forward)
<andrewrk>
stage1 can compile C++ code
<andrewrk>
LLVM and clang have C++ APIs
<andrewrk>
(unfortunately)
<winksaville>
couldn't stage3 spawn clang++ to compile c++ code?
<Hejsil>
Then there should be no question (I think) as for the semantics the person is trying to describe
<Hejsil>
Or!
<Hejsil>
We can just use my terms! "static/dynamic interfaces"
<Hejsil>
I think that covers everything!
<winksaville>
Where can I find the definition of "static/dynamic interfaces"?
<Hejsil>
Idk, made them up just now
<Hejsil>
Mostly joking, but it would be nice if we didn't have 10 words for the same things
<Hejsil>
And "static/dynamic interfaces" draws parallels to "static/dynamic typing" so I think it's not the worst wordings i've ever come up with
<winksaville>
"interface" to me means a set of method signatures that may have multiple implementations. Not sure how to modify that with "static/dynamic". What is your definition of "interface"?
<Hejsil>
Ye, maybe interface is not the best word. I want something simular to "type"
<Hejsil>
Actually, the wording is not to far of what i want
<Hejsil>
By static/dynamic, I just mean when things are resolved
davr0s has joined #zig
<Hejsil>
Just like types
<Hejsil>
So a static interface would try to resolve calls to methods and field access at compile time
<Hejsil>
While dynamic would be a runtime
<Hejsil>
So OOP is "dynamic interfaces"
<Hejsil>
And concepts is "static interfaces"
<bheads_>
so traits and classes :)
<winksaville>
You say OOP is "dynamic interfaces" do mean type hierarchies or method dispatching or something else?
<Hejsil>
method dispatching
<bheads_>
which doesn';t really define OOP
<Hejsil>
That is really most of what makes OOP what it is
<Hejsil>
Well, we embed types into eachother to
<Hejsil>
Ok, actually there is a word for what I want!
<Hejsil>
Dynamic dispatch
<Hejsil>
There we go!
<Hejsil>
Do we have one word for "concept" like things?
<bheads_>
depends on the impl
<Hejsil>
True
<Hejsil>
Mostly, i just want one "concept" proposal, and one "dynamic dispatch" proposal
<winksaville>
so is "Dynamic dispatch" is dispatching through "vtables" when a c++ method is "virtual" as opposed to non-virtual c++ methods are resolved at compile?
<Hejsil>
Right now, I think there are 5 and they kinda discuss both static and dynamic
<bheads_>
I am trying to envision dynamic dispatch in zig
<bheads_>
and not vtable sillyness
<winksaville>
s/so is/so/
<Hejsil>
winksaville, ye, that about covers it
<Hejsil>
I think you need some way of storing a pointer to some functions in dynamic dispatch
<Hejsil>
Or lookup based om some enum
<Hejsil>
Is there some other dynamic dispatching that does not do "vtables"
<bheads_>
okay but how would this work: foo(a); foo(b); or a.foo(); b.foo();
<bheads_>
nothing dynamic here
<Hejsil>
Well, who knows what foo does :)
<Hejsil>
Could have a user implemented vtable in there
<winksaville>
but a->foo() might be dynamic
<Hejsil>
Hmm, right. C++ does communicate a possible dynamic dispatch
<Hejsil>
Though, if you do OOP, most of you methods calls will be ->foo, even if they are static
<Hejsil>
non-virtual
<Hejsil>
geeh, words
<bheads_>
yeah all this needs to be comptime
<bheads_>
only function pointers can be dynamic
<bheads_>
also cant alias a struct in a struct, you need to name it
<winksaville>
you can also dispatch using switch on value/enum without vtable or function pointers, but that doesn't give you polymorphic behavior. To get polymorphism I think you need function pointers or other dynamic way to choose the call target based on some "other" information such as "type".
<bheads_>
there might be something there if the concepts/traits/duck typing/interface supports defining function pointers
<winksaville>
slightly off topic but concerning pointers, does zig support "move semantics" or notion of "ownership"?
<winksaville>
andrewrk: line 66 of src-self-hosted/ir.zig on your hello world branch has a typo, "populated durign codegen".
<Hejsil>
winksaville, no but it has been discussed plenty
<Hejsil>
So far, there has not been anything Ziggy enough
<Hejsil>
As far as I know
<Hejsil>
I think ownership is difficult for memory, because not all allocators actually give out ownership to memory
<Hejsil>
Some, like Arena or Fixed Allocator owns the memory they give out
Bas_ has joined #zig
<winksaville>
My use case is supporting asynchronous messaging and when I send a message I'd sure like to "move" it to the target so that I don't accidentally have an alias and modify it after sending.
<bheads_>
how big is the message?
<Hejsil>
I think with https://github.com/ziglang/zig/issues/287 you could do `fn move(something: *SomeType) res: SomeType { move something into res...; something.* = undefined }`
<Hejsil>
Though, this would only catch you using moved values at runtime
<Hejsil>
so not ideal
Bas_ has quit [Ping timeout: 252 seconds]
<bheads_>
one simple idea is a move assignment just for optional types
<bheads_>
ie: a <== b; b is now null, a is what b was
<Hejsil>
Still only runtime checked, and using b is now a pain
<Hejsil>
b.?.acess_member
<winksaville>
a message is arbirtary in size, although smaller the better. At a minumum it would probably be ver, cmd, src, target, flags plus any user data of arbitrary sizes.
<bheads_>
winksaville, I am just suggesting that sometimes the cost of a copy is less then the over head so thread safe moving a message
<bheads_>
optional types will always be a pain
<winksaville>
bheads_: a <== b LGTM, and I'd expect the compiler to enforce me not using it after "sending" so shouldn't be a pain to use.
<bheads_>
well the compiler will know b is now null
<bheads_>
same problem as var a: ?int = null; ... compile knows a is null
<Hejsil>
Could use undefined then.
<Hejsil>
var a: int = 2; var b <== a; // a is now undefined
<Hejsil>
And the compiler knows, for some cases that a is undefined
Bas_ has joined #zig
<Hejsil>
as long as complicated branching doesn't occure
<Hejsil>
Though, then var a: u8 = 2; var b = move(&a); // move sets a to undefined
<Hejsil>
should work as well
<bheads_>
you need to rewrite that stack pointers then
<Hejsil>
Passing ptr to a
<bheads_>
var a: i32 = 1; var p = &a; var b <== a; where is p pointing?
<Bas_>
What is <== ?
<Hejsil>
p would point to a
<bheads_>
some made up move assingment operator
<Hejsil>
i don't see the problem
<Hejsil>
Zig doens't prove lifetime, so it can't catch this
<Hejsil>
(maybe it could) but it would never be perfect without profs
<winksaville>
what is "profs"
very-mediocre has quit [Ping timeout: 252 seconds]
<Hejsil>
Sorrym *proofs
<winksaville>
Bas_: <== a proposed "move" assignment
<bheads_>
I just dont see the purpose of moving primitive types
<winksaville>
In my simple use case I want `send(message.dest, <== message);`
<Hejsil>
Lol
<Hejsil>
Well, small text messages require simple examples
<winksaville>
Hejsil: u laughing at me :)
<Hejsil>
Naah, it was the "moving primitive types" :)
<bheads_>
so how do you move a struct on the stack?
<bheads_>
something I never understood
<winksaville>
you need to move the struct as a whole or disallow it, in my case I'd be happy saying it has to be allocated on the heap.
<Bas_>
You don't move a struct anyway :P
<Bas_>
maybe you can copy the pointer ^^
<bheads_>
so.... why not share the heap between the producer and consumer...
<bheads_>
then your just transfering ownership
<bheads_>
so is move copy ellusion or an ownership issue
<Hejsil>
Isn't moves purely and ownership issue?
<bheads_>
I guess so, I always struggled with this concept
<Hejsil>
And i C++, to avoid copy ctor, which Zig doesn't have
<bheads_>
so to move you need either an optional type or you need to copy the src to dest and re init the src
<winksaville>
call it ownership transfer or move either way I'd like the compiler to slap my hand if I try to "use" something after sending it.
<bheads_>
The copiler would need to track null or undefined access in comptime
<Hejsil>
bheads_ or have the compile complain using moved values
<Hejsil>
I think this discussion is a good example of "move semantics are complicated", and therefore we should probalby/maybe/onlymyopinion not have them
<Bas_>
C++ also doesn't complain if you move stuff
<bheads_>
I would agree Hejsil
<winksaville>
:( you giving up to easy
<Hejsil>
lol
<winksaville>
s/you/your/
<bheads_>
I think a nice to have would be detecting accessing null or undefined at comptime would be a good feature
<Hejsil>
True
<Bas_>
And I actually think that often RAII makes people lazy and not think about ownership.
<bheads_>
but that is not related to move
<Hejsil>
And Im sure that will come with a good control flow analysis pass in the compiler
<MajorLag2>
I feel like I should demonstrate something like a handle system as an alternative to building move-semantics into the language for things like this.
<bheads_>
you can always make a new block and defer
<Hejsil>
MajorLag2 plz do
<Hejsil>
Would love to see alternatives
<bheads_>
though if send bubbled up an error you could leak...
<Bas_>
or just do send(dest, message); message = null; ^^
<MajorLag2>
My todo list is already so long though...
<Hejsil>
:(
<winksaville>
bheads_: I like "{ defer message = null; send(message.dest, message); }" good solution I can use now!!
<bheads_>
:D
<bheads_>
winksaville, only problem I can see is error handling, sometimes I think we need an okdefer
<Bas_>
You can also use it to: moveMessage(* Message m) { defer m.* = null; return m.*; }
<bheads_>
Bas_, wouldn't that have to be a ** to null the source pointer?
<Bas_>
Maybe...
<bheads_>
This is why java has ruined my brain
<bheads_>
anything beyond a single pointer makes me have to think
<Bas_>
It depends on whether you have your message as a pointer or by value
<Bas_>
setting the message to null also doesn't work. :P
<Bas_>
moveMessage(*?Message m) ...
<bheads_>
yeah it has to be optional
<Bas_>
moveMessage(**Message m) ...
<Bas_>
one of those should work
<bheads_>
lol, just keep adding one of these * & ?
<bheads_>
hummm maybe we do need an okdefer
<winksaville>
Yep, I'll use one of those for now, but in an ideal world i'd like a send binary operator "<<==" so I could say `message.dest <<== message` and have the compiler error if message use used after that point.
mahmudov has joined #zig
<bheads_>
fn foo(... stuff ..) { var t = sql_start_transaction(); errdefer sql_roll_back(t); okdefer sql_commit(t); ... do sqly stuff .. }
<winksaville>
Maybe by limiting "move/ownership" to this simple case it wouldn't be hard to implement?
<Bas_>
can't you just put your okdefer as the last statement in the function?
<bheads_>
depends on the flow control
<Bas_>
hmm yeah ok
<winksaville>
everyone, txs for the help on how to send a message with zig now, in the furture I may advocate for a "send operator" but next I need some advice on how to construct a message.
<winksaville>
I see all messages having a header at the beginning followed by arbitrary stuff after the header and ideally I'd like to construct the message at comptime. I suspect it's possible any example code?
<bheads_>
Do you mean a generic type?
<bheads_>
or do you mean const messages made at comptime?
<winksaville>
I'm not sure but a possible usage syntax might be `const MyMessage = Message({ id: u64, data: []u8});` and it would make `struct { header: messageHeader, id: u64, data: []u8};`
<diginet>
I noticed that Zig has Type: Type, but impredicative type systems of this form are known to be inconsistent, am I missing something?
<diginet>
(cf. martin-lof's original type theory)
<Hejsil>
Idk, there doesn't seem to be problems with the type type
<Hejsil>
As far as I know
<bheads_>
first class types are really useful
andi3 has joined #zig
<andi3>
@Bas_ you have to read "The UNIX- HATERS Handbook" regarding worse is better, its ridicules, granted giving anyone working on unix a really good laugh :DD
Tobba has quit [Read error: Connection reset by peer]
andi3 has quit [Client Quit]
<diginet>
the UHH is great
<diginet>
Hejsil, bheads_ it is indeed useful, I'm just worried that it's unsound
<diginet>
Type: Type in Zig is a compile-time construct though, right?
<bheads_>
whats Type: Type ? there is comptime t: type
<Hejsil>
Do you mean `const SomeType: type = struct {}`
<diginet>
bheads_: I mean the type of tpyes
<bheads_>
I belive Type is only a comptime concept
<Hejsil>
Yes, type is only a comptime concept
<andrewrk>
diginet, what's wrong with `type`? do you have a code example?
hopppetosse has joined #zig
<andrewrk>
if I'm being honest I probably will never read martin-lof's original type theory
Bas_ has quit [Ping timeout: 252 seconds]
Bas_ has joined #zig
<diginet>
andrewrk: I haven't studied Zig closely enough to say, but impredicative type systems can theoretically fall victim to a type-level analogue of Russell's paradox
<bheads_>
I am not sure how zig has impredicative types
<diginet>
perhaps it does not and I am mistaken, I was just curious if this problem had come up before
<diginet>
there is another language, Seed7 which reminds me of Zig's first class types
minus has quit [Quit: Bye]
minus has joined #zig
Bas_ has quit [Ping timeout: 252 seconds]
hopppetosse has left #zig ["Leaving"]
hopppetosse has joined #zig
very-mediocre has joined #zig
<very-mediocre>
re:type type
<very-mediocre>
all structs are subtypes of type, yet zig has no inheritance...
<very-mediocre>
i think that's theoretically unsound but works nonetheless.
<very-mediocre>
pretty sure that's how most languages do it too
<very-mediocre>
If you're gonna be academic about it, the fact that you can pass "Cat" or"Dog" as a "Type" param is polymorphic.
<very-mediocre>
or a union is also a "type"
<very-mediocre>
late night drunken ramblings, disregard if way off :)
<GitHub78>
zig/master 1f4c7d5 Jimmi HC: Fixed windows getPos
Triplefox[m] has quit [Ping timeout: 245 seconds]
clebermatheus[m] has quit [Ping timeout: 260 seconds]
LordeKumamon[m] has quit [Ping timeout: 255 seconds]
kammd[m] has quit [Ping timeout: 240 seconds]
pqflx3[m] has quit [Ping timeout: 256 seconds]
sg-james[m] has quit [Ping timeout: 260 seconds]
dtz[m] has quit [Ping timeout: 260 seconds]
bb010g[m] has quit [Ping timeout: 276 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
tiehuis has joined #zig
<tiehuis>
andrewrk: regarding bitcount, it actually adds on an extra bit for signed integers already, however, its not currently optimal in a twos-complement signed context
<tiehuis>
further, sizeInBase is more like the traditional gmp sizeInBase, in that it will always return a lower-bound but may be off by 1 (or maybe 2)
<tiehuis>
bitCount should assume twos-complement though so it can be changed to handle that
<tiehuis>
i'll be back in ~2 hours so if you haven't looked at it then i'll add some tests and change it
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
winksaville has quit [Quit: Page closed]
winksaville has joined #zig
zolk3ri has quit [Quit: leaving]
zolk3ri has joined #zig
<winksaville>
In the docs the term "optional" is used but it seems to me that using "nullable" might be better. In my mind "opitional" would be the term I'd used to explain that a parameter is optional if a "default" value for a parameter was provided.
pqflx3[m] has joined #zig
Hejsil has quit [Ping timeout: 252 seconds]
davr0s has joined #zig
kammd[m] has joined #zig
bb010g[m] has joined #zig
dtz[m] has joined #zig
LordeKumamon[m] has joined #zig
sg-james[m] has joined #zig
clebermatheus[m] has joined #zig
Triplefox[m] has joined #zig
Tobba has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]