<daurnimator>
Tetralux: `show(struct{})` or also `show(usize(1234))`: essentially being able to call it on anything.
<diltsman>
Does Zig support Spir-V as a target?
<fengb>
LLVM doesn't support it natively so Zig currently doesn't either
<emekankurumeh[m]>
there is an open issue for spir-v as a target
<emekankurumeh[m]>
there is also llvm-ir to spir-v transpiler
<diltsman>
Ok. I couldn't remember if that was resolved or not.
<emekankurumeh[m]>
with the coroutine rewrite should we really rely on llvm specific features? would that make transitioning to other backends harder?
noonien has quit [Quit: Connection closed for inactivity]
<fengb>
Coroutine is no longer LLVM specific
Ichorio has quit [Ping timeout: 264 seconds]
hio has quit [Quit: Connection closed for inactivity]
<Tetralux>
daurnimator: If 'type' is able to be a runtime value, isn't that just typeid/typeinfo?
<emekankurumeh[m]>
I know, I mean the "prefix data" stuff
<Tetralux>
daurnimator: i.e: `show(usize)` == `show(@typeInfo(usize))` or `show(@typeOf(usize))` ?
<daurnimator>
Tetralux: wut?
<Tetralux>
Unless I'm missing something obvious, doesn't what your suggesting amount to converting a `type` to a `typeid` or `TypeInfo` implicitly if you pass it at runtime?
<daurnimator>
Tetralux: `show(usize(5))` ==> shows the number 5. `show(usize)` shows info about the type usize
<daurnimator>
`@typeOf(usize) == type`
<Tetralux>
I don't know how/if you can get/a typeid from a value.
<Tetralux>
But I know you can get the info from one.
<Tetralux>
But that's not the point
<Tetralux>
Point is, `show(T: type)` -- What does it _mean_ for the type to be at runtime?
<Tetralux>
Surely typeid or typeinfo.
<daurnimator>
Tetralux: it's `show(x: var)`
<Tetralux>
Yeah - but `var` just means "specialize to whatever you pass` , right.
<Tetralux>
So it'd get specialized to `show(anything: type)` if you passed a type.
<daurnimator>
okay
<Tetralux>
But we have typeid/typeinfo already.
<daurnimator>
and then in such a function, it would be valid to do `@typeId(anything)`
<Tetralux>
So
<Tetralux>
To be clear
<Tetralux>
I generally like the idea.
<Tetralux>
But my inclination is that if you pass a 'type' to a fn at runtime, it would not be of type `type`.
<Tetralux>
Because that's the type of a comptime version of a type.
<Tetralux>
Like
<Tetralux>
Okay
<Tetralux>
I'm maybe not being clear.
<Tetralux>
If 'type' can be runtime, what's the reason for having typeid/typeinfo.
<Tetralux>
Does it make sense for there to be three such things?
<Tetralux>
I'm not really seeing the advantage of having three over two.
<Tetralux>
But perhaps it's just not clear to me.
<daurnimator>
Tetralux: I don't understand the question
<daurnimator>
Tetralux: the reason for @typeInfo is to get information about a type...
<Tetralux>
Indeed.
<Tetralux>
i.e: the runtime version of a 'type'.
<daurnimator>
?
<daurnimator>
a typeinfo is not runtime
<Tetralux>
Or rather, the metadata about a type.
<Tetralux>
(.. which is available at runtime.)
<daurnimator>
@typeInfo is rarely valid in a runtime variable
<Tetralux>
But typeid is also available at runtime.
<daurnimator>
pieces of it are. but @typeInfo for most types contains comptime_ints, and child `type`s.
laaron- has quit [Remote host closed the connection]
<Tetralux>
.. Whereas typeid is basically just an integer that's unique to a particular type.
<daurnimator>
no it's not... @typeId is the enum of type.... types.
<Tetralux>
I'm not sure that makes sense to me xD
<nrdmn>
is there any good way to completely disable stack probing in PE binaries?
<daurnimator>
Tetralux: @typeId returns the type of a type => i.e. Bool vs Int vs Struct vs etc.
<daurnimator>
`subtype` might be a better word
<Tetralux>
Sounds like `typeOf` might be a better word xD
<daurnimator>
??
<Tetralux>
That sounds like it should be an enum field on TypeInfo.
<daurnimator>
it is
<daurnimator>
TypeInfo is a union over TypeId
<Tetralux>
OH
<Tetralux>
So TypeId is the tag type for TypeInfo?
<daurnimator>
yes
<Tetralux>
OKAY
<Tetralux>
That makes a touch more sense.
<daurnimator>
WHY ARE WE YELLING
laaron has joined #zig
<Tetralux>
XDDD
<Tetralux>
BECAUSE IM YELLING
<Tetralux>
IM HAVING A REALISATION OVER HERE OKA\Y
<Tetralux>
I'm not sure why you'd want to have `typeid` be a type, when you have builtin.TypeId.
<Tetralux>
Since it's just the tag type.
<Tetralux>
But still.
<daurnimator>
what?>
<Tetralux>
show(t: typeid)
<Tetralux>
instead of just `show(t: builtin.TypeId)`
<daurnimator>
did anyone propose that?
<Tetralux>
I'm pretty sure I've seen code with that.
<Tetralux>
Though, you're surprise makes me question myself a tad xD
<daurnimator>
I don't see that used anywhere in the standard library
<Tetralux>
Hmmm.
<Tetralux>
Odd.
<Tetralux>
/shrug
<Tetralux>
XD
<Tetralux>
But yes - if it's fair to say that both type and TypeInfo are compile time, then the difference between them is just that one is for typechecking, and the other is metadata?
<Tetralux>
Is that a fair summation
<scientes>
Tetralux, generally you are only going to pass around types
<scientes>
or var
<scientes>
everything is is just to manipulate the types
<scientes>
*everything else
<Tetralux>
Makes sense.
<scientes>
I just ran into that today
<scientes>
I will have to create a function that examines a var, and checks if the type is the type passed, or a vector with that as the scalar type
<scientes>
and throws a @compileError() otherwise
<Tetralux>
I might be a little spoiled from how Jai has you pass around typeinfos at runtime and only handles variables of type `type` at comptime. :D
<scientes>
that sounds like dynamic typing
<scientes>
we have had proposal for that, mainly stemming from wanting to return values attached to errors
<Tetralux>
Nah - doing `show(usize)` in Jai would essentially the same as `show(@typeInfo(usize))` in Zig.
<Tetralux>
IIUC.
<Tetralux>
It's been a while since I saw him show that off.
<Tetralux>
Except that TypeInfo in Jai, is not comptime.
<scientes>
i really dislike dynamic typing
<scientes>
because a bunch of errors get pushed to run-time
<scientes>
that could be caught at compile-time
<scientes>
maybe we should have sets of types
<scientes>
instead of just "var"
<scientes>
type theory is really complicated...
<Tetralux>
Meh.
<Tetralux>
I like var, because it means something specific: specialize to whatever type you pass.
<Tetralux>
Though maybe that could be more explicit?
<scientes>
well you end up writing your own type checking code
<scientes>
I haven't worked with haskell much or really understoood it, but people that do say the type system is great
<Tetralux>
I haven't needed to try yet
<Tetralux>
But I'd start off trying to just assume I can do certain things with the type.
<fengb>
The people who can understand the type system say it's great :P
<torque>
is a union not a set of types
<Tetralux>
(the var of the type passed)
<torque>
I guess the issue is runtime specialization with unions
<Tetralux>
In my limited experience, it's kinda wordy - like Java. But "worse.2
<Tetralux>
"worse."
<scientes>
torque, yes
<scientes>
you need a way to tag the union with an enum
<scientes>
and then the grainy issue of trying to provide type safety to that, and even compile out the enum at times
<scientes>
cause dynamic types actually kinda suck
<fengb>
You could use it as a pseudo functional type union but it's still statically defined
<scientes>
yeah but you are checking the type id
<torque>
dynamic types suck a lot which is why people have spent ridiculous amounts of effort shoehorning static typing into languages that are inherently dynamically typed (see typescript and python)
<fengb>
So it's not as flexible as an ML-like union
<scientes>
like full-blown dynamic typing really sucks, but having sets of types is quite reasonable at times
<torque>
julia has the most understandable and expressive typing system I've run into (though there are probably other languages that are as good or better)
<fengb>
Haskell is expressive :P
<fengb>
Elm is understandable >_>
<scientes>
zig's type system is already quite expressive
<scientes>
**quite rich
<scientes>
but not very expressive
<fengb>
On principle, I kinda wish Zig has traits or interfaces or something of the sort... but I haven't encountered a strong need
<scientes>
it has interfaces
<scientes>
compile-time
<fengb>
I mean runtime
<scientes>
but why?
<fengb>
Zig's generics is surprisingly good
<scientes>
what does that give you
<scientes>
fengb, beautiful
<scientes>
i'm kinda a zero-cost abstraction person
<fengb>
The allocator "interface" is pretty kludgy
<fengb>
It works but it's via magic pointer offset voodoo that's easy to break
<scientes>
its not voodoo
<scientes>
@fieldParentPtr is better than Linux's container_of() macro
<scientes>
and it is also zero-cost
<fengb>
There's a ticket that explains the cost. It's hostile to LLVM optimizations
<scientes>
but yes there is a good proposal to add type safety to @fieldParentPtr()
<fengb>
I think it's pretty cool we have userland interfaces, but it also feels rather hacky
diltsman has quit [Read error: Connection reset by peer]
<scientes>
@fieldParentPtr is something that go fundamentally can't do
<fengb>
But again... I haven't encountered a strong reason in awhile. Just a principle thing that I want some sort of dynamic dispatch :P
<scientes>
and they are tons of cludges in go to do half of what it does
<Tetralux>
Or well - not quite cuz those are more static.
<Tetralux>
But dyn traits -- nope.
<fengb>
I just want a little polymophism. I've gotten by with function pointers just fine, but that's because I have statically defined fields
<fengb>
But again... it's a "want", not a need so far
<scientes>
fengb, yeah it would be nice to have "safe" dynamic casts
<scientes>
not only @fieldParentPtr, but also specialization
<scientes>
like IrInstruction in stage1
<scientes>
but I guess that is union(enum)
<fengb>
Union only works if you know all the types ahead of time. Although... most of the complex usecases I can remember about using polymorphism were all predefined
<scientes>
wut?
<scientes>
types are always comptime
<fengb>
nvm
<scientes>
uggh, its late i should go to sleep
<scientes>
what about a ways to limit the amount of language features a program uses?
<scientes>
nah
<scientes>
that is only relevent if you want your langauge to be "safe"
Sobeston has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
ntgg has joined #zig
darithorn has quit [Quit: Leaving]
ntgg has quit [Quit: Lost terminal]
<emekankurumeh[m]>
Sobeston did you make any progress on that issue you were having earlier?
_whitelogger has joined #zig
<emekankurumeh[m]>
grr, i just figured out the error i was having
<emekankurumeh[m]>
linking libc for mingw-w64 moves the section with the pdb info
<emekankurumeh[m]>
i just realized lld can generate dwarf debug info for windows executables, so that raises the question when building zig executables on windows for mingw do we use pdb or dwarf?
<gonz_>
I would assume tools will have pdb support
<gonz_>
There are debuggers that will read pdb but not the way llvm creates them, as well, for example
<gonz_>
so the most valuable option on Windows is to do it exactly the way `cl` would do it
<gonz_>
The `RemedyBG` debugger doesn't work properly with zig, for example.
<gonz_>
Happily windbg does
<emekankurumeh[m]>
is the issue with lld's pdb's
<gonz_>
As far as I can see on their issue tracker it's something like that, yes
<gonz_>
They don't read the way lld/LLVM does it
<gonz_>
Presumably this should be an easy add for them, but they're not prioritizing it
<gonz_>
I think one ought to try everything and see what works best, obviously
_whitelogger has joined #zig
ArtlessMaladroit has joined #zig
<ArtlessMaladroit>
Hello community, attempted convertee here. I'm trying to port some projects to Zig to get myself familiar with it and I've run into a road block with function pointers. I'm trying to do something like: "pub const FnAlias = ?extern fn([*]const u8, ...); pub var FnPtr: FnAlias = null;" which I then later assign to at runtime with "FnPtr = @ptrCast(Fn
<ArtlessMaladroit>
Alias, addrOrigFn);" this is all fine but then when I later try to call it like: "FnPtr(args);" it reults in a compile error that the type isn't a function. What's the proper way to do this, or if not this, achieve the same effect of converting an address to a potentially null function pointer?
<gonz_>
ArtlessMaladroit: Can you put a minimal example of what you want up on godbolt for people to see what you mean and play around with?
<gonz_>
Just to double check as well, is this on master?
<ArtlessMaladroit>
I think I'm a bit behind: version 0.4.0+1547692d I'll go download master now and check though
<gonz_>
I have no idea how much recent activity has been done on this, but you never know without talking to andrewrk
<ArtlessMaladroit>
Yeah, the error persists on master as well. I'll follow the progress of the issue, just wanted to make sure I wasn't just doing something very wrong. Appreciate the feedback.
<gonz_>
Is the use case trying to load one of the many different versions of DLLs depending on which is available, etc.?
<ArtlessMaladroit>
Yep, getting the module of a loaded dll then calling GetProcAddress and attempting to assign that to a global variable to be called from elsewhere.
kristoff_it has joined #zig
_whitelogger has joined #zig
Ichorio has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
ArtlessMaladroit has quit [Ping timeout: 260 seconds]
<Sahnvour>
gonz_: interesting remedyBG doesn't work with zig executables, because LLVM tries to follow PDB format as closely as possible
<Sahnvour>
and in fact does, because it can build complex C++ project and have native debugging working perfectly with windbg/visual studio
<gonz_>
Reality is often disappointing.
<gonz_>
The highest hit rate with regards to debugger friendliness will undoubtedly be "do it exactly how `cl` does it" regardless of whichever values one has.
NI33_ has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
<scientes>
what about a bit pointer type
<scientes>
(that can't be volatile)
<scientes>
cause large bit manipulation is so painful
<Akuli>
there are systems where c's char is u16 or u32
<scientes>
yeah we should probably have c_char there too because of that
<companion_cube>
anyway, the unit for utf8
<Tetralux>
Personally, I'd find 'oct' (for octet) easier to type than u8 - not that I'm seriously suggesting that change.
<Akuli>
put your index finger on u, middle finger goes to 8 automagically
<Akuli>
u8
<companion_cube>
u8 is very explicit ♥
<Akuli>
(sorry i assumed that you are using a querty keyboard)
<Tetralux>
Akuli: I just haven't needed to type u8 _that_ often in comparsion to normal typing and so my muscle memory for it is not quite as fast as it might otherwise be.
<Tetralux>
I also do like both the consistency and simplictly of u8.
<Tetralux>
I like u8.
<Tetralux>
I just don't like typing u8 xD
<scientes>
Tetralux, it isn't an octet, that would be u3
<Akuli>
to type oct, i type o with my right hand middle finger, then i type both c and t with left hand index finger, moving it from c to t
<companion_cube>
const myByte = u8; ?
<Akuli>
hmm
<Akuli>
const hex = u8;
<Tetralux>
Akuli: I type 'o' with my right hand and the other two with my left. All index fingers.
<Tetralux>
scientes: No, it is octet.
<Tetralux>
That's a well established name for a byte AFAIK.
<Tetralux>
(A byte that is 8 bits.)
<companion_cube>
ugh, this C code does so many ugly things
<Tetralux>
Perhaps I'm wrong but... :)
<Tetralux>
Akuli: Well yeah, I could define const oct = u8, but then it doesn't light up in my highlighting and I feel sad xD
<Akuli>
write a better highlighter :D
<Tetralux>
No point - it's Sublime.
<Akuli>
i think there should be a way to put common typedef names or similar in editorconfig
<Tetralux>
I just don't wanna have to fiddle with it.
<Tetralux>
I want to have an editor that just works (TM).
<Tetralux>
I've considered 4Coder. It has some things I like, but...
<Tetralux>
Not there y et.
<Akuli>
tbh it just uses a library for highlighting
<Akuli>
but that library is customizable
<Tetralux>
Does it just have Py highlighting?
<Akuli>
no it highlights pretty much anything
<Tetralux>
Nope - just read that part in the readme xD
<Tetralux>
Pygments is what Github uses no?
<Akuli>
github used pygments before i think, they don't use it anymore
<Tetralux>
Only, I program in Odin too and GH doesn't have highlighting for that.
<companion_cube>
you like to live on the edge
<Tetralux>
I like to use nice tools x)
<fengb>
How about V then? :P
<Tetralux>
I'm the guy that wants to buy a £15 mechanical pencil.
<Tetralux>
But doesn't do that very often.
<Tetralux>
I have... questions about... V. xD
<Tetralux>
If I had the complete source code of it, then... /shrug.
<Tetralux>
Depends how nice it is to use and debug stuff with.
<fengb>
It’s been released
<companion_cube>
there's 0.1% chance that V will yield anything useful ever
<Tetralux>
One of my biggest complaints is that there isn't really a good debugger on Windows.
<Tetralux>
VS is basically all you've got.
<Tetralux>
GDB is damn near a hazard to install on windows.
<scientes>
just debugg in wine
<Tetralux>
And debug info is off in VS.
<Tetralux>
(off meaning not entirely accurate)
<Tetralux>
I could, but that's god-awful slow.
<Tetralux>
Though it does help you debug bad winapi calls which is a godsend.
<Tetralux>
I didn't know it did that.
<Tetralux>
wine-dbg takes over five seconds to even begin running the program.
<Tetralux>
I like having a simple lightweight interface where I can easily _discover_ how to use it/
<Tetralux>
Like data breakpoints. I'd have to wade through text menus to figure out how to do that in gdb.
<Tetralux>
VS isn't really much better. If at all.
<Tetralux>
I don't wanna spend hours figuring out how to do the thing I want.
<Tetralux>
I want to ask it and have it tell me.
<Akuli>
look it up on google :)
<Tetralux>
That's why I like the windows start search so much.
<Akuli>
i know about 4 gdb commands and it's enough for my debugging needs
<scientes>
eventually you will need reversable debugging
<scientes>
and conditional breakpoints
<scientes>
but yeah i was like you for a long time Akuli
<Akuli>
don't tell me what i need, i survived for years with print
<Akuli>
not in c though
<scientes>
oh wow
<Akuli>
but i still debug everything with print in other programming languages
<scientes>
well of course
<Akuli>
it's easy and it works
<scientes>
but debuggers are nice
<Akuli>
i think i have actually used the python debugger like once
<Tetralux>
Personally, I want to see someone write a debugger where you can just search for keywords about what you want to do, and it just tells you and lays out how to do it.
<companion_cube>
print is nice for logic bugs, debugguers for index/memory errors, in my experience
<Akuli>
i just valgrind to find memory issues :D
<Tetralux>
print is terrible if you want to monitor multiple things at once and see if one changes as you step though.
<Akuli>
so are my 4 debugger commands, why would i want to do that? lol
<Sahnvour>
Tetralux: what do you mean debug info is off in VS ?
<Tetralux>
In C/C++ it only shows you the line, not the stmt that's running, and in Odin/Zig it doesn't even correctly do that.
<Sahnvour>
well that depends more on the debug info itself
<Tetralux>
Sometimes you have to press step-forwards twice to go to the next line.
<Tetralux>
This is rediculous man xD
<Akuli>
if line only is a problem, you have too much stuff on your lines
<Tetralux>
I tend to like to do things like `if (!x) return 0, false` etc.
<Tetralux>
But still
<Tetralux>
For instance
<Sahnvour>
in zig it actually does highlight the expression being run, and there can be multiple ones on the same line
<Tetralux>
Maybe you want `f(g(x))` to show you what g(x) gives back
<companion_cube>
so when you write in a higher level language, most errors are logic errors so debugguers are less useful
<scientes>
if your language is turing complete you will have to debug it at some point
<Tetralux>
Like
<Tetralux>
Don't get me wrong
<Tetralux>
I think that Zig's stack traces for errors are very useful.
<Tetralux>
The less time I spend in a debugger the better.
<Tetralux>
But I still want to have a debugger.
<Tetralux>
If I have a complex program, I probably need a debugger.
<Tetralux>
Though, if any language has a chance of overcoming that
<Tetralux>
I'd probably be Zig.
<Tetralux>
JUST because of those traces, and segfault traces, and memory traces in general because of the debug allocator.
<scientes>
yeah i kinda agree
<Sahnvour>
all these things are nice to have, but nothing new and don't remove the need for a debugger ever, I think. In any sufficiently complex program you will end up having to inspect its state when the behaviour seems wrong.
<companion_cube>
hmm, in vim I used to have error report on save, but not anymore — is it because the build requires --library c inthis case?
<Sahnvour>
bugs are not just about crashes and memory leaks
<scientes>
Sahnvour, it still saves you when you can't reproduce the problem
<scientes>
so i think its a good idea
<Sahnvour>
it's great indeed, just not solving every problem where a debugger is handy :)
<scientes>
UML just introduced time travel
<scientes>
so time jumps forward if there is nothing to do
<scientes>
and you can even set it to make all cpu take zero time
<Tetralux>
Akuli: Awwh dangit - the editor doesn't have DPI awareness?
<scientes>
yeah, maybe i wont buy a 4K laptop
<Tetralux>
Oh?
<Tetralux>
I did. I'm spoilt for life now.
<Tetralux>
Text is nice to read now xD
<gonz_>
I think there are certain circumstances that make debuggers more or less useful. In Erlang I've literally never wanted a debugger because all the interesting bugs happen in code that does message passing.
<gonz_>
Using stop-the-world debugging in a system like that will change the entire dynamic of the system and effectively make it behave abnormally.
<scientes>
how do i test if the bits in one number are differn't from the bits in another number, i.e. 1010 | 0101 (differn't), vs 1010 | 1101 (some the same) ?
<scientes>
oh, you have to do assert(a | b == a & b)
<fengb>
Xor
<scientes>
** assert(a | b == a ^ b)
<fengb>
If there's *any same*, that'd be `a ^ b != 0`
<scientes>
fengb, not true
<scientes>
for intersection you need both or and xor
<fengb>
Oops, that's any different. I got it mixed up
_whitelogger has joined #zig
<scientes>
which is actuall nor
<scientes>
*nor
<scientes>
and you can do everything in a computer with only nor and if
<Tetralux>
I'm not entirely sure if you're serious or not xD
<Akuli>
i am
<Akuli>
i know about pixels and not much else
<Tetralux>
To my knowledge, high DPI will not work on programs that do not declare themselves as "DPI aware"
<Tetralux>
This means that on high-res screens (like 4k screens) the program with render things blurry.
<Akuli>
pixely or blurry?
<Tetralux>
Blurry.
<Tetralux>
Because it's basically a bitmap scale.
<Akuli>
how else would a display work than with a bitmap scale?
<Tetralux>
But if they are DPI aware, then they automatically (I'm not sure if Windows does it or the program does it) render things at the larger size.
<Tetralux>
So fonts that are drawn will be drawn at a larger point size.
<Tetralux>
For example.
<fengb>
On a Mac, they treat high DPI at a lower resolution: 2880x1800 is treated as 1440x900 in the math
<Akuli>
does a font with size 12px render with more than 12px of precision?
<fengb>
So if you're not high DPI aware, it'll render as upscaled 1440x900
<Tetralux>
fengb: You mean they render at a large size and scale down if not DPI aware?
<fengb>
No I mean they're rendered at "native" 1440x900 and then scaled up to 2880x1800 physical pixels
<Tetralux>
Does "native" mean "the size of your primary screen" ?
<fengb>
Dunno how it works on other OSs, but the Mac basically has "half pixels" on HDPI
<Tetralux>
Akuli: If DPI aware, it'll essentially just increase the font size to be the appropriate amount, rather than bitmap upscaling it.
<Tetralux>
I don't know how you actually make that work though. I *think* it does it automatically if you do the winapi call to declare that you are dpi aware.
<Akuli>
which operating system do you have?
<Tetralux>
But I've never actually written a program that uses it so I don't actually know.
<Tetralux>
Win 10 x64.
<Akuli>
i only have windows 10 in a vm, and it eats up 4gb of ram every time i start it, lol
<Akuli>
not exactly a thing i want to touch when not needed
<Akuli>
if you can get it to work, please send a pull request :)
<fengb>
Fonts are mostly vector based so I'd expect most fonts to behave correctly at HDPI, e.g. 12px might not be physical pixels
<Akuli>
you can call winapi functions from python with ctypes, something like ctypes.winapi.SetProcessDpiAwareness(1)
<fengb>
Tetralux: my terminology is confusing. Mac treats 2880x1800 physical pixels as 1440x900 software pixels. And each software pixels can be referenced via float half-pixel
<Tetralux>
Giving 1 to SetProcessDpiAwareness means that it only detects the DPI at startup (bad) - and 2 means it updates when the DPI changes (like if you drag it onto a different monitor) (good.)
<Tetralux>
If it's 1, it takes the DPI of the monitor it first appears on, at first glance.
wootehfoot has joined #zig
dimenus has joined #zig
reductum has joined #zig
noonien has joined #zig
<scientes>
wow, once you get use to zig's safety C is painful
<companion_cube>
once you tried anything else…
<scientes>
heh, I like C!
jjido has joined #zig
<scientes>
…
<scientes>
hmm compose plus TWO . is …
<scientes>
should be three
<companion_cube>
…
<companion_cube>
‽¿¡
<companion_cube>
damn I'm spoiled by languages with stdlib docs and LSP :s
<scientes>
LSP?
<companion_cube>
language server protocol
<companion_cube>
I mean a semantic plugin
<scientes>
well i don't have enough memory for that
<scientes>
even for c/c++
<Akuli>
some day i'll implement lsp support in my editor :D
<Akuli>
for now, grep ftw
<companion_cube>
well works for OCaml and rust :s (even though the rust plugin could be improved)
<companion_cube>
jeez I dislike this block expression syntax so much
<hryx>
companion_cube: what do you dislike about it?
<scientes>
the blocks are so powerful
<scientes>
and awesome, because you can comptime initialize things
<scientes>
they are def. differn't, but once you start getting use to them
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<companion_cube>
hryx: it's verbose and there's a useless name
<companion_cube>
I just want {foo; bar; x} -_-
<companion_cube>
(so it's easy to turn `x` into `{ warn(whatev); x }` and conversely, for example)
<scientes>
but that would break the arguments are const thing
<scientes>
well i guess it wouldn't have to
<scientes>
what is wrong with "return x"
<hryx>
the label isn't useless when you have nested blocks, but a lot of people do wish for the ability to break without one
<hryx>
there was discussion recently on GitHub if I recall
<scientes>
explicit returns are ugly and a thing of dynamically typed languages
<scientes>
not really a fan
<scientes>
*implicit returns
<companion_cube>
hryx: it should be optional ten
<companion_cube>
then*
<Tetralux>
"Only one way to do things."
<companion_cube>
like, sure, if you have a weird case where you want to return from several nested blocks, name the outside one
<companion_cube>
same as for loops
<companion_cube>
would you want to name every single loop?
<scientes>
Tetralux, optional names I don't think beaks that
<scientes>
its still the same way
<Tetralux>
I meant optional return to break with a value
<companion_cube>
also `return` I find a bit ugly too, but well
<scientes>
yeah I can see making the name optional
<scientes>
but I like the "return"
<companion_cube>
(again it's useful for early return, but shouldn't be required for one liners)
<scientes>
it means that everthing is a statement
<Tetralux>
While I've become a little more okay with naming every block I'm returning a value from than I was when I started, I still have the same idea of not wanting to _have_ to name it.
<companion_cube>
everything should be an expression :/
<scientes>
although I guess return is a little weird, because it comes from C where sizeof alignof offsetof and return are special things
<scientes>
that are not functions
<Tetralux>
Arguing that return is from C seems a little weird to me.
<companion_cube>
just pick rust's syntax and remove the traits, borrow checker, and use simpler error handling :p
<Tetralux>
And impl syntax.
<companion_cube>
yeah sure
<Tetralux>
And generic syntax.
<companion_cube>
but the expression syntax is awesome, imho
<companion_cube>
it's nonambiguous and clean
<Tetralux>
That's in the form of:
<companion_cube>
(again with the `while … { … }` and `if … { … }` without parenthesis but with mandatory braces)
<scientes>
what's wrong with zig error handling companion_cube ?
<Tetralux>
`let x = { code; return x; }
<hryx>
sorry, I can't find the discussion about breaking to parent block without a label. I think the proposed word was `result`
<scientes>
I have a few issues, but I think the idea is sound
<hryx>
there may have also been a proposal for implicitly returning last expression but not sure
<scientes>
hryx, yuck, just use "break"
<companion_cube>
scientes: it's good!
<companion_cube>
I mean, it's one of the differences with rust
<hryx>
scientes: wasn't my proposal
<scientes>
yes
<fengb>
hryx: it ended up being rejected as being too foreign and named blocks are “good enough”
<companion_cube>
but what I mean is that syntax is my least favorite part of zig
<companion_cube>
well, it's good, but it could be closer to rust and gain from it imho
<Tetralux>
Oh yeah - and that semicolon after the block name when you break?
<Tetralux>
SOMETIMES YOU NEED TO PUT IT BEFORE THE NAME AND NOT AFTER
<scientes>
fengb, but we already have implicit scope with while and for
<fengb>
Yeah, the break emulates C / Java style where it’s loop based
<scientes>
and if() is not a block
<scientes>
for the implicit scope
<fengb>
Block based return languages don’t have a good return keyword afaik
<scientes>
we already have these rules for while and for
<scientes>
so just expand it to include result blocks
<fengb>
I think it’s not ideal... but it fits existing paradigms. I kinda wish there’s a breakloop keyword and break is just nearest block
<scientes>
with break returning a value (and continue and next compile errors)
<companion_cube>
I just wish it'd be as simple as rust -_-
<scientes>
otherwise, you could have two differn't sets of implicit blocks, and return could be the keyword
<fengb>
Or make loop breaking the weird case that needs a label
<scientes>
because it does not make sense to return from a function in a initialization block
<scientes>
but then what if you wanted to return an error?
<scientes>
uggh
<scientes>
so probably break
<scientes>
yeah closures would make sense here as is mentioned
<scientes>
and you could return an error by using try to run the closure
<fengb>
I don't want a closure just to break. Reminds me of IIFE hacks in JS
<scientes>
closures don't have to be ugly
<scientes>
look at how go does them
<companion_cube>
|x| { x+1 }
<companion_cube>
or `fn(x) { x+1 }` maybe
<fengb>
I also don't like the Go version. Specifically, immediate execution closure is basically a block
<hryx>
yeah, in Go you commonly find IIFE too
<hryx>
namely in defer
<fengb>
Like... go func() {} is a programmer error but the compiler won't warn you
<fengb>
Whereas a Zig-like block would be `go {}` and really hard to screw up
<scientes>
but why can't blocks be closures
<scientes>
you would just have to add a (); at the end
<scientes>
ahh yeah that is a problem, you don't always want to have to add ();
<companion_cube>
😱
<fengb>
Because they aren't the same? I suppose you could make them the same but you need syntax to distinguish definition versus execution
<scientes>
but they are if you immediately run them and they don't take arguments
<companion_cube>
what's wrong with `fn (x) { … }` ?
<scientes>
oh, binding variables
<scientes>
i see
<fengb>
Still different from defining and executing. Go style forces you to run it, which is easy to forget
Akuli has quit [Quit: Leaving]
<scientes>
companion_cube, so fn (x) { … }(foo); ?
<companion_cube>
uh, no, I meant for writing actual closures
<fengb>
Oof, I forgot Go doesn't actually capture the variable in a sane way
<companion_cube>
why would you do that?
<scientes>
companion_cube, you wouldn't but you could
<companion_cube>
yeah but there's no point
<hryx>
Does anyone here have experience reading the output of --verbose-ir? I could use some tips on getting started
<fengb>
Anyway, I think closures are out of scope here. We can use them to emulate blocks, but we don't have them and they open a can of worms on where to store the context
<scientes>
companion_cube, more like fn (x: u32) { |x| … }
<Tetralux>
fengb: Maybe.
<Tetralux>
Whatcha got?
<scientes>
ohhhh i see
<scientes>
not annonymous functions, but closures
<scientes>
differn't things
<scientes>
I'm too use to C
<scientes>
yeah, I would be happy with annonymous functions
<scientes>
for now
<scientes>
as fengb says, closures are a can of worms
<scientes>
C's lack of annonymous functions is annoying
<hryx>
"can of worms" was my experience when daydreaming about closures in zig
<fengb>
There's a proposal and I think they're a good idea, but I'm not sure how cleanup would happen
<companion_cube>
yeah memory management is messy
<scientes>
fengb, but how about implementing annonymous functions now, and thinking about closures later
<companion_cube>
and it's probably superseeded by coroutines anyway
<companion_cube>
they could capture the scope though
<companion_cube>
it'd be compiled as a function with additional arguments
<scientes>
I like the variables in the {}
<scientes>
`foo.sort({ |x, y| x.a > y.a })`
<scientes>
but I think having it match function syntax is better
<fengb>
Let's drop the parents too! `foo.sort { |x, y| x.a > yxa }` :P
<scientes>
so like `foo.sort(fn(x: u32, y: u32) bool { return x.a > y.a; })`
<companion_cube>
`var i = …; foo.sort(|x, y| { x.a + i < y.a + i });
<scientes>
strongly typed too, as it should be
<scientes>
so identical syntax, you just leave out the symbol name
avoidr has quit [Quit: leaving]
<fengb>
I think the biggest challenge with closures is how to deal with mutations, e.g. what happens when reassigning `i` in your example
<scientes>
also that example is horrible, you have to have a way to specify that i is bound to the function
<fengb>
Java resolved it by only allowing `final` variables to be closable
<scientes>
fengb, well that is why you pass it like a function
<fengb>
scientes: closures imply automatic binding, usually via lexical scoping
<scientes>
but when you define it
<companion_cube>
it really is a can of worms…
<scientes>
fengb, ewww, I guess I haven't really used closures, but just using lexical scoping seems gross
<fengb>
(Doesn't have to be lexical... but languages that do dynamic scoping are terrible)
<scientes>
it should be passed, just before execution
<scientes>
then you don't have the variable-ish problem
<fengb>
It's the basis for most MLs and Lisps
<scientes>
but anyways, I don't use closures, but I want annonymous functions
<scientes>
I will eventually use them if they exist
<scientes>
maybe...
<scientes>
but it sure sounds horrible
<scientes>
perhaps co-routines are better
<scientes>
as those also keep state
<hryx>
mikdusan: if you're around, any tips on getting started with zig IR / --verbose-ir? I have your "minimal boilerplate" gist, but don't know how to read the output
<companion_cube>
closures are just one shot coroutines
<scientes>
yeah, then why no leap-frog them and have coroutines
<scientes>
(and also annonymous functions)
<fengb>
companion_cube: not if you talk to a functional programmer :P
<companion_cube>
you could have a short syntax for closures that just give you a coroutine 🤷
<companion_cube>
fengb: why not? :)
<fengb>
Because if you can't return a closure, it's not a "real" closure
<companion_cube>
well you could, just malloc and copy the closure there, right?
<companion_cube>
ah that's assuming capture by value though
<mq32>
oh the closure topic. i'm in!
<fengb>
You can't if your context references are mutable
<scientes>
well I guess I just haven't used them
<scientes>
so I don't know what they are useful for
<fengb>
But... you can't mutate in functional programming so it works
<scientes>
and haven't seen how to optimize them either
<mq32>
scientes, most simple example is targetet callbacks
<companion_cube>
I feel like a fanboy, but look at what rust does? :D
<mq32>
imagine having a list of callback functions that all require some logic with context to execute
<companion_cube>
(it's not simple though)
<fengb>
Nothing in Rust is simple :P
<mq32>
you can do the c-style-thing (functionptr + void*) or use a closure, where you capture the void* context in the closure itself
<companion_cube>
fengb: the syntax is pretty simple
<mq32>
companion_cube, i think syntax is not a problem at all ^^
<companion_cube>
I think it's a big deal
<companion_cube>
syntax makes some things easy and some things cumbersome
<fengb>
Syntax is the least of my worries here. Storing variables sounds like a nightmare when dealing with manual memory
<mq32>
what fengb says
<mq32>
syntax is something to talk about when all other stuff is safely designed
<scientes>
WTF< why is buf_write_value_bytes big-endian?
* companion_cube
thinks syntax has an influence on things like goto fail;
<scientes>
ho wait it isn't
<scientes>
its little, it just has weird padding
<companion_cube>
but yeah, when talking about closures it's not the first priority, semantics is
<fengb>
Some things have colliding syntax. I think whatever we agree on with closures will look pretty close to current functions and proposed anon functions
<fengb>
I'm more scared of the ramifications of when variables go out of scope, how they get copied, how we can pass around closures, etc.
<mq32>
i'll take a look at how Rust implements closures
<companion_cube>
with traits
<companion_cube>
but you have several flavors of closures, which is pretty neat
<mq32>
so they actually go the same way as c++?
<companion_cube>
(either by ref, or by move)
<companion_cube>
I'm not sure about the details for C++, but in rust each closure is a nameless type which implements one of Fn, FnMut, FnOnce
<companion_cube>
(depending on whether it captures by move (value), or by const/mutable ref)
<mq32>
yeah
<Tetralux>
I'm curious where the storage for captures vars goes.
<mq32>
in C++ every closure is a class that implements a function call operator
<companion_cube>
for moved closures, you have this nameless type which is basically a struct
<companion_cube>
by-move closures*
<fengb>
My brain hurts already. I'm gonna go back to coding :P
<companion_cube>
so you can put that in a box (malloc) or just return it on the stack, or whatever
<companion_cube>
for the by-ref closures, you have to respect scopes otherwise the borrow checker yells
<mq32>
hm
<mq32>
so they go full c++ with more hurdles :D
<Tetralux>
I'm honestly not sure you need to have closures.
<mq32>
it's useful some times
<fengb>
Having the borrow checker yelling at you is a good thing. I hope we can't get to a point where we get an invalid stack reference because we used the closure wrong... eventually
<mq32>
but: most closure tasks could be done with fnptr+context*
<companion_cube>
less hurdles, more safety, mq32 :p
<Tetralux>
mq32: Indeed. But where do you put the context?
<fengb>
Hmm, I wonder if we can solve it with a coroutine. Stick the @Frame wherever you want and you get full control of the lifecycle
<Tetralux>
You would statically allocate it as part of the function pointer.
<mq32>
Tetralux: in most cases: on the stack
<companion_cube>
in which case you have to respect the same constraints as rust's borrow checker imposes
<fengb>
I really want to see the new coroutines in action. It feels like it can do so much :P
<Tetralux>
Like a closure could be: struct { context: FnContext, proc: fn(FnContext, ...) }
marijnfs has joined #zig
<mq32>
i just got an idea…
<mq32>
where's my compiler explorer?
<scientes>
uggh this padding in bigint.cpp is so weird
<scientes>
its using big endian padding on little endian
<mq32>
oh, found a compiler bug i think…
<scientes>
welcome to the club :)
<mq32>
yeah :D
<mq32>
playing around and it seems like you can't capture @typeOf() through function layers
<mq32>
this is how closured *could* be done with near-usespace-experience
<scientes>
its cool to see people in here using my SIMD work
<mq32>
the function types would have to be somehow comptime generated
<companion_cube>
like coroutines, right?
<mq32>
i think my example could actually work without compiler support if @reify would be implemented and we could "enforce" an argument list like c++ variadic templates
<mq32>
but my main idea is to have a "closure type" which is a struct that 1) provides a pointer to a function and a context, 2) stores all captured variables (by-ptr or by-val) and 3) implicitly casts to it's corresponding closure type
<mq32>
3 could work by the "go style inheritance" proposal
<mq32>
companion_cube, yes, i think so. maybe a whole lot of the coroutine stuff could be reused for closures
<mq32>
hm
<mq32>
yeah, a closure would be a endless-loop-coroutine then
<mq32>
except for that a "resume" passes in new arguments to the coroutine
<companion_cube>
ah, if you can call it several times, interesting
<mq32>
closures are meant to be called several times, usually
<mq32>
scientes, i got another nice example for you :)
<mq32>
var i : i32 = 0; list.forEach(fn(x : i32) { i += x; });
<mq32>
generic forEach that can accumulate or calculate arbitrary stuff
<Tetralux>
Is that cleaner or clearer than just a for loop though?
<companion_cube>
it can be
<Tetralux>
I can't say I've seen a good example of that.
<Tetralux>
Though as someone who's played around with linq in their time
<companion_cube>
if it's something a lot more complicated to iterate on, than a list
<companion_cube>
(eg a tree)
<Tetralux>
If you foreach a tree, surely the for isn't THAT much worse.
<mq32>
Tetralux, yeah for an array a simple loop would surely be better
<companion_cube>
heh, what about code reuse?
<companion_cube>
what if it's a HAMT/radix tree? the iteration logic becomes non trivila
<companion_cube>
trivial
<mq32>
but if the enumeration type is more complex (imagine a sparse array structure), it's better to reuse the iteration code than rewrite it every time
<companion_cube>
ofc you could also have iterators.
<mq32>
we would'nt neet one if we have closures :D
<hryx>
currently seen as `... while(iterator.next()) ...`
<mq32>
yeah, that' true :D
<hryx>
don't get me wrong mq32, I think closures are cool :>
<fengb>
I mean, technically you wouldn't need anything else if you had closures :P
reductum has quit [Quit: WeeChat 2.5]
<mq32>
hryx, wanted to say: for me closures aren't much more than neat syntax sugar that allows some code to be better to read because of less clutter
<companion_cube>
but is it still C like then?
<mq32>
closures *can* be done in C and are often done
<mq32>
but with manual work
<mq32>
which is cumbersome and and error-prone
<hryx>
mq32, agreed but there's actually one odd thing that closures would actually bring (albeit horribly roundabout way). In the `iterator.next()` approach, you can't make anything inside `iterator` private. see #2059
<mq32>
my browser tells me i should stop reading so much issues on the zig language repo :D
<mq32>
if i type "zi" my browser autocompletes to the issues tab
<hryx>
your browser is encouraging you to read more of them!
<mq32>
:)
<mq32>
on the private/public stuff:
<mq32>
i've stopped using "private" in my code unless you can *actually* break memory safety
<mq32>
in most of my structs all fields are public
<mq32>
and i noticed that most of the code gets better in quality
<mq32>
less code → less errors, better readability, less code to maintain, …
<hryx>
interesting observation, very cool
<mq32>
but there are reasons to hide state
<mq32>
like safe memory handling (in C++ with alloc-on-ctor, free-on-dtor) and similar
ntgg has joined #zig
<mq32>
this stuff is mostly private
<hryx>
I see. luckily not an issue in zigland
<hryx>
my main concern is, does lack of `pub` mean a leakier or weaker API for the user?
<hryx>
I honestly don't know but my guess would be seeing all the "private" fields adds noise for the consumer
<mq32>
yeah, that's some stuff that annoys me in c++ from day 1
<Tetralux>
Yeah - I like POD.
<Tetralux>
So private isn't really in my vocab.
<Tetralux>
Though private to file scope is.
<Tetralux>
That seems useful.
<fengb>
I believe that we need a "this is API stuff" and "thar be dragons". Accessibility isn't what I care about
<hryx>
mq32 I'll keep in mind what you said about not having private leading to better quality code
<fengb>
Although I do prefer nothing to be inaccessible cause then I can't work around poor assumptions/designs/bugs
<mq32>
hryx: i have to code with c++builder @ work and it's sometimes horrible how bad your code *has* to be in order to actually compile
ntgg has quit [Ping timeout: 246 seconds]
<scientes>
uggh, the padding of bigint.cpp is big-endian on little-endian architectures
<scientes>
and my code is going forward and backwards
<scientes>
and had to pack bits
<scientes>
this could be so much simpler with bit-granularity types
<scientes>
and pointers
<scientes>
and i cant used unsigned, because i have to support types large than 64-bits
<scientes>
its madness
<scientes>
i had something working, but then i ran into backwards padding
<scientes>
and now its all to hell trying to support that
<scientes>
maybe i should just us an array of bools
<scientes>
that would make the logic much simpler
_whitelogger has joined #zig
laaron has joined #zig
dimenus has quit [Remote host closed the connection]