<marler8997>
goodness, people, I'm not saying these things are good ideas, I'm trying to talk about how these features affect the language, good or bad
<marler8997>
dominikh, I don't think your comments are being productive here, I'm here to discuss and learn
<marler8997>
with whole program optimization
<marler8997>
ikskuh yes that's what I thought yesterday, but thinking about it, I think you could actually optimize dynamic dispatch away
<marler8997>
dominkh, yes I agree, again, just discussing implications
<marler8997>
ikskuh, you could be right but I'm not sure, for example, Andres suggested to me that the Allocator interface could get completely optimized away
<marler8997>
dominkh, again, not talking about proposing features, just discussing how features affect the language
<marler8997>
sorry we're saying too many things and I'm not matching up our responses
<marler8997>
that's the other solution, maybe you assume GC and let the optimizer remove it...
<marler8997>
but maybe there needs to be some way for AnyTypes to become values types semantically
<marler8997>
obviously the optimizer could turn an AnyType into values
<marler8997>
throw any of my suggestions out the window if needed
<marler8997>
ikskuh, well that's just my idea, the question is, how do you solve this problem in a language without generics
<marler8997>
how do you solve that?
<marler8997>
right that's a no go
<marler8997>
because all AnyType values are references....
<marler8997>
we require using pointers/references because without generics we need a runtime representation of all types, but now how do we copy values...
<marler8997>
yeah, that simple example does pose an issue
<marler8997>
thinking...
<marler8997>
I don't see what the issue is though
<marler8997>
for case 3, T is AnyType
<marler8997>
I don't see the issue with case 2 though
<marler8997>
I think case 2 would have to return AnyType
<marler8997>
reading...
<marler8997>
I'm wondering what all the implications are
<marler8997>
ikskuh maybe, not necessarily just wondering if it's a good idea though
<marler8997>
to be able to support AnyType, it must expose it as a pointer
<marler8997>
the stack
<marler8997>
neither does this allocate on the heap
<marler8997>
Zig already does this
<marler8997>
what isn't explicit?
<marler8997>
dominkh I want to address your issues but I need an example
<marler8997>
I'm sure there are issues but I'm looking for an example to demonstrate them
<marler8997>
companion_cube, what fails?
<marler8997>
the point isn't making the compiler simpler, it's making the language simpler by removing this feature. I dont' know if it makes the compiler simpler or not
<marler8997>
dominkh, you're saying we can't support Zero Cost Abstraction with this?
<marler8997>
if we can't maintain Zero Cost Abstraction and remove generics, then the whole idea is DOA
<marler8997>
dominkh, well the whole idea depends on the optimizer to maintain Zero Cost Abstraction
<marler8997>
companion_cube, yes
<marler8997>
you can't do tha without talking about the optimizer
<marler8997>
dominky, you're wanting to discuss the runtime implications of this
<marler8997>
and the function foo, could support this tagged union, or could be generated multiple times
<marler8997>
the ideal optimizer would turn myGlobal into a tagged union union { Slice: []const u8, Int: u32 }
<marler8997>
this would force myGlobal to handle both slices and u32
<marler8997>
so foo is called with a runtime slice and a runtime u32 lets' say
<marler8997>
foo(argv[0]) and foo(parseInt(argv[1]))
<marler8997>
dominikh I agree but we need to nail down a specifc example to address it....foo(argv[0]) for example
<marler8997>
what dominkh is doing is what I'm looking for
<marler8997>
I just want a discussion on how it would affect the language
<marler8997>
it's not a proposal though
<marler8997>
but everyone here seems to have strong opinions on it
<marler8997>
you didn't ask what it was :)
<marler8997>
you're correct
<marler8997>
I like where you're going with this, I'm just trying to be very precise
<marler8997>
sorry, I'm a math guy so I've very explicit, and it can slow things down
<marler8997>
*the next constraint
<marler8997>
the next contains could be, assume foo is called with a runtime value yes?
<marler8997>
the value passed to the function is stored in a global
<marler8997>
dominikh, I followed your constrant and myGlobal being of type comptime_int adheres to it
<marler8997>
it won't even have memory at runtime
<marler8997>
then myGlobal will be of type comptime_int
<marler8997>
if foo gets called once with a comptime_int of 100
<marler8997>
not necessarily
<marler8997>
so you want to make AnyType available to C code?
<marler8997>
what do you mean by "export" specifically?
<marler8997>
if it's not being used, then nothing gets generated
<marler8997>
how is myGlobal being used?
<marler8997>
you example is incomplete
<marler8997>
dominkh, we aren't depending on the optimizer to change the semantics of the source code
<dominikh>
marler8997: it does when you depend on the optimizer to remove the need for allocations…
<marler8997>
dominikh, optimizer has nothing to do with whether something compiles
<marler8997>
Zig allocates an lvalue on the stack and passes a pointer to it...Zig already supports this behavior
<marler8997>
dominikh yes, then no
<marler8997>
that could definitely be one of the weaknesses, the programmer has "less" control over how the final output is manifested
<marler8997>
dominiky, yes, changing code in one place can change the entire program!
<marler8997>
huh?
<marler8997>
dominikh the user needs to do allocation all the time because the optimizer is fallible?
<marler8997>
companion_cube, the point is to remove a big feature of the language to make it simpler
<marler8997>
dominkh, yes there will be examples where runtime allocations may be necessary
<marler8997>
dominiky, runtime allocations optimized into no allocations
<marler8997>
companion_cube, it could be optimized into exactly what generics do today
<marler8997>
dominikh, it means removing a big feature of the language
<marler8997>
companion_cube, semantically yes (but remember, could be optimized)
<companion_cube>
marler8997: there would still be basic generics with comptime, anyway.
<marler8997>
discuss the merits of removing generics from the language for dynamic dispatch?
<marler8997>
ok, good idea
<marler8997>
but the first thing people say is "runtime overhead"
<marler8997>
dominikh yes
<marler8997>
ikskuh yeah me too, if you find an issue would be good to know
<marler8997>
from the callers perspective, there are no pointers
<companion_cube>
If you take AnyType to be GObject I think you get what marler8997 is talking about
<marler8997>
fn (foo: AnyType) void {} foo(100)
<marler8997>
ikskuh you're example wasn't the proposed semantics
<marler8997>
the discussion assumes the optimizer could do this
<marler8997>
"the optimizer isn't in place"...I'm not sure why you said that then
<marler8997>
what would the language look like
<marler8997>
I'm just wanting to discuss the implications of it
<marler8997>
I'm not saying I want this feature
<marler8997>
ikskuh, you're acting as if I'm a proponent of this feature and you're trying to attack it saying you don't want it
<companion_cube>
marler8997: so simplifying a bit the language but making it dependent on an optimiser? Meh
<marler8997>
dominikh, the benefit is the language no longer needs to support generics with anytype
<ikskuh>
marler8997: the optimizer isn't in place here
<ikskuh>
marler8997: how can i do this then? fn(foo: anytype) @TypeOf(foo){ return foo; }
<marler8997>
it's always a "ref" in terms of source code, but it could be a value once the optimizer gets through
<marler8997>
dominiky, the optimizier would HAVE to support that as well
<ikskuh>
companion_cube: marler8997 said it's always a ref
<dominikh>
marler8997: generate multiple copies of a function, one per concrete type of the generic argument
<marler8997>
ikskuh you wouldn't pass a pointer
<marler8997>
dominikh I don't know what monomophization means but it *sounds* correct...lol :)
<marler8997>
even if you use AnyType as an argument, it doesn't mean you'll need to support it at runtime
<marler8997>
no
<marler8997>
but keep in mind, the optimizer can remove any need to store AnyType at runtime
<marler8997>
I mean AnyType :)
<marler8997>
you can store anytype
<marler8997>
foo(100)
<marler8997>
fn foo(x: AnyType) void { }
<marler8997>
ikskuh yes, you're no longer the one who decides these things, the optimizer does, that is a key difference here
<ikskuh>
marler8997: const T = struct { foo: AnyType };
<marler8997>
well, not necessarily, the poitner could be optimized away
<marler8997>
yes it contains a pointer
<marler8997>
I mean, it wouldn't bey *AnyType
<marler8997>
AnyType wouldn't be a pointer
<marler8997>
but then the optimizer could remove everything
<marler8997>
so, you would code all these things like they are available at runtime
<marler8997>
why a pointer? because Zig's model requires parameters to have a fixed size
<marler8997>
is it runtime accessible, it could be or it could not be
<marler8997>
g-w1, yes
<marler8997>
I would hold up making any judgements on the topic without fully understanding it
<marler8997>
companion_cube: you wouldn't allocate anytype parameters explicitly
<ikskuh>
marler8997: relying on the optimizer is a horrible idea and imho leads to bad design desitions
<companion_cube>
marler8997: allocations are explicit, the optimizer won't remove them AFAIK
<marler8997>
otherwise, if you do need the overhead, the compiler has multiple methods available such as 1) instantiating multiple functions (basically what generics do today) 2) instantiating one function that supports variant types
<marler8997>
companion_cube, well first, you wouldn't need to allocate anything if the optimizer determines you don't need to
<marler8997>
This may seem like it incurs runtime overhead, but the idea is that Zig's optimizer should be able to remove any overhead incurred
<marler8997>
so, replace every anytype with AnyType, which contains a pointer to a value and type metadata
<marler8997>
by generics the only thing I mean is "anytype"
<marler8997>
comptime and generics are orthogonal
<ikskuh>
marler8997: can you elaborate that?
<ifreund>
marler8997: I'm curious about what you're saying but I don't follow. You mean zig without comptime? "generics" are kind just a side affect of that feature
<marler8997>
andrewrk, been thinking about what you said about concrete types vs generics, it's making me think about what Zig would look like without generics, actually, I think it could be done. Basically any time you would need generics, you just use indirection instead (this is what Python does under the hood). Something to ponder about
<marler8997>
14 open issues
2020-12-02
<marler8997>
g-w1, just saw your PR, the realpath substituation may not work
<marler8997_>
should I create an issue about the "bring your own os" working with the Zig build system, so we document this issue?
<marler8997_>
btw, I'm on Windows 10 now so I'm not blocked by this Windows 7 issue, and I think I can work around not having windows 7 support on my other machines (knowing some day I'll have a path around it). So I would say let's only support windows 7 if it's more than just me who is wanting it
<marler8997_>
andrewrk, yeah that makes sense, for example we could have a packages that support older versions of windows, but would that approach work with our zig build system?
<marler8997_>
I'm fine with Zig limiting official support, I just want to know there's a reasonable path to unofficially support things as well
<marler8997_>
pixelherodev, that's one approach, there are downsides though, the time it takes to review/design a good library that supports everything is non-trivial
<andrewrk>
thanks marler8997_
<pixelherodev>
marler8997_: or we support everything in stdlib and have people contribute?
<marler8997_>
I feel like with a good package manager the standard library issue can be solved through packages, but if the Zig build system doesn't work then we're really make it hard on people to make Zig work on unsupported platforms
<marler8997_>
maybe we need to have a competing standard library that aims to be a drop in replacement for the main standard library but supports as many platforms as people want to add to it...a compatibility standard library? Just throwing around ideas
<marler8997_>
one idea I have is that even if Zig STD only supports modern platforms, we may want to make the Zig build system support all platforms we can
<marler8997_>
I've been thinking about solutions and I'm having a difficult time with it, maybe you've thought about this already and have thoughts/insight to share
<marler8997_>
but I still think something doesn't feel right with our approach here
<marler8997_>
I created an issue specific to windows 7 where I propose extending support until 2022
<marler8997_>
although, even if we just said "let's support Windows 7", I'm still pondering and thinking about this problem in the general case...I'm not sure what we should be doing to address it
<marler8997_>
sure
<andrewrk>
marler8997_, can you open an official proposal to specifically change the windows version range? I want to take this proposal seriously
<marler8997_>
Something doesn't "feel right" here and I think I need some clarification on the plan/goals
<marler8997_>
This issue is giving me pause on how much time I'm investing in writing Zig code, it sounds like I won't be able to use that code in all the places I would like
<marler8997_>
A couple of unsupported class values in NtQueryFileInformation
<marler8997_>
pixelherodev, the one that came up today is Windows 7, since I can't run "zig build" on windows 7 anymore because we're now using unsupported functionality
<pixelherodev>
marler8997_: what platforms do we not support?
<marler8997_>
plan is for these things? Is the plan that you just won't be able to use Zig code on these older platforms?
<marler8997_>
andrewrk, one thing I didn't really consider, choosing not to drop support for platforms in the standard library not only means programs for those platforms need to use alternate libraries, it also means they can't make use of the Zig build system. So to have a Zig project that works on an older system, you'd have to not only support an alternate standard library, but find an alternative build system...I'm trying to see what the
2020-11-27
<marler8997>
TheLemonMan, with my new Windows 10 and your branch, "test-std" didn't crash for me...I'm running the full test suite now
<marler8997>
I'm back...new shiny Windows 10
<marler8997_>
I mean, can you use the "file" command to tell what it is?
<pixelherodev>
marler8997_: no
<marler8997_>
curl > myfile; file myfile ?
<marler8997_>
novaskell yeah that syntax looks pretty clean, reminds me of lisp
<novaskell>
marler8997_: guix is a lot cleaner in the package definitions (everything must be build from source) and all* tooling for guix exists as guile modules making it easier to automate. Less packages overall though that hasn't been much of an issue and non-free packages exist in separate repositories which can be added as channels.
<marler8997_>
pixelherodev, yeah I think I remember hearing they only support "free" software
<marler8997_>
novaskell, have you compared guix with nixos? I haven't looked into guix but heard they have similarities
<marler8997_>
well after 11 years of using windows 7 on my main gaming rig, it looks like if I want to keep using Zig I'm going to have to upgrade to 10....wish me luck
<marler8997_>
nixos, windows 7, windows 10, ubuntu are the main ones
<marler8997_>
we should take a poll, what Operating Systems do yall use here?
<marler8997_>
like, my guess is it will have over 10% for another 3 or 4 years
<marler8997_>
and again, I'm fine with dropping support, I'm just making the argument here that I think it's way to soon for Windows 7
<marler8997_>
unfortunately
<marler8997_>
I anticipate at least some changes would probably have to be invasive
<marler8997_>
andrewrk, yes that's why it would probably be impossible to support an older OS without community buy in
<marler8997_>
although, I wonder if there are nother OS's in the same boat? Older mac versions?
<marler8997_>
sure, but we don't have to be precise here
<marler8997_>
Windows 7 is such an odd duck because of Microsoft's bullshit
<marler8997_>
I would probably ammend it with, platforms that share 10% of the desktop market...
<marler8997_>
lol
<andrewrk>
maybe the policy can be amended with, "and we also support Windows 7 thanks to marler8997_"
<andrewrk>
marler8997_, honestly you are involved enough in the zig project that the bare fact that you want windows 7 support is an important factor
<marler8997_>
I write alot of tools in Zig, with this decision you're saying I can't run my code on those machines
<marler8997_>
I have multiple machines which run it, some of which can't run linux because of drivers and some of which can't run Windows 10 beacuse it's performance is unusable
<marler8997_>
18% market share means Windows 7 is one of the highest use Operating systems in the world
<marler8997_>
looks like XP is less than 2% market share, please stay in the real world here
<marler8997_>
and not to qualify it with "non-invasive" support
<marler8997_>
no difference, what I need from you is to say yes, we will support Windows 7 if someone wants to do the work, in which case I can work on fixing it and potentially add testing for it
<andrewrk>
marler8997_, I mean what's the difference really between saying "revisit this later" and having an open bug report that is so low priority that it doesn't get addressed for years?
<marler8997_>
I'm saying that using market share keep the scope limited, manageable
<marler8997_>
You said you want to keep the work mangeable (so it doesn't get out of hand)
<marler8997_>
I'm not sure the argument of "taking work away" is valid here, you can use that arguemnt against literally anything
<marler8997_>
you're not going to get 20 platforms with 15% market share :)
<marler8997_>
by definition, there are only so many of them :)
<marler8997_>
you don't think supporting platforms with high market shares is manegeable?
<marler8997_>
so if an OS has 90% market share, but the company doesn't support it, neither will Zig std?
<marler8997_>
What criteria are you using to determine what platforms to support?
<marler8997_>
that's a steep uphill battle I wouldn't win
<marler8997_>
if Zig doesn't support windows 7, I can't spend all my time constantly fixing it and fighting people with whether or not my changes would be considered "invasive"
<ericonr>
marler8997_: do you connect windows 7 to the internet?
<andrewrk>
marler8997_, I'm sorry :( one of the hardest things I have to do in this job is say "no" to people to avoid scope creep
<marler8997_>
erconer, I don't know where you're getting these rules from
<ericonr>
marler8997_: if you have software that needs to run on an unsupported OS, that doesn't get most security updates, you really shouldn't use said insecure OS for anything else but said software
<marler8997_>
this really is a downer for me
<marler8997_>
also going to have to reconsider what to do about my audio program I'm developing on Windows 7
<marler8997_>
so you're saying I can't use zig anymore on these machines that have to use Windows 7?
<marler8997_>
if a platform has 18 market share, you're signing up for at most 6 platforms :)
<marler8997_>
right, I'm not saying let's support everything here
<marler8997_>
and the problem here is not that I choose to use Windows 7, it's that some software only works (or only works well) on windows 7, and that's because of its market share
<marler8997_>
whether or not a company supports their own closed source OS is a very important factor, however, when they drop support but it stil has 18% market share of all desktops in the world, I think the market share would take precedence
<marler8997_>
andrewrk, completely agree
<marler8997_>
this has nothing to do with the Zig language, it's the standard library
<marler8997_>
so, people who work on retro hardware are irresponsible? That's a first for me
<marler8997_>
lol
<marler8997_>
so 23% * .8 = 18% total
<marler8997_>
and windows has around 80% Total
<marler8997_>
nah, I realized the 23% number was Windows Market Share not Total Market Share
<marler8997_>
lol
<marler8997_>
at some point support for all OS's can be dropped, but 18% market share seems way too soon for me
<marler8997_>
lol
<marler8997_>
only developers can do this
<marler8997_>
yeah, updates break our old legacy builds
<marler8997_>
My work uses Windows 7 for example, means I can no longer use Zig on my work machines
<marler8997_>
you're putting me in a tight spot here
<marler8997_>
actually, I think it's 23% share of all windows machines, which is 80% of total I think. so actualy share is around 18% I think
<marler8997_>
right, but 23% desktop market share
<marler8997_>
it looks like there are more Windows 7 uers than all mac users combined...so if we drop support for Windows 7, then should we also drop support for all Mac users?
<marler8997_>
so, zig is borked on Windows 7, the FileNormalizedNameInformation class that we use when calling NtQueryInformationFile during a "zig build" doesn't exist on Windows 7. However, it seems we don't support Windows 7? But it looks like Windows 7 still has 23% desktop market share (one user incldues me)....can we reconsider this decision not to support Windows 7?
<marler8997_>
yes, the older brother whose matured past his days of unending treats
<marler8997_>
I'm the code monster, feed me code
<marler8997_>
yes please
<KIMI>
marler8997_ the little struct is so i can send you guys a paste so you can check with minimal noise in my code :D
<marler8997_>
sure
<marler8997_>
yeah
<TheLemonMan>
yo marler8997_, are you on windows?
<marler8997_>
my first question would be why you are creating an array of the Glyph structs, who's only field is a usize named "width"? Do you need it to be usize?
2020-11-26
<KIMI>
marler8997 thanks!
<marler8997>
who der?
<marler8997>
who dat?
2020-11-25
<marler8997>
stripRight or trimRight probably
<marler8997>
KIMI, after you read the line and check it isn't null, you can strip the "\r" character off the end
<ikskuh>
marler8997: lld-link: error: could not open 'libcmt.lib': No such file or directory
<ikskuh>
marler8997: linux → windows, x86_64-windows, Release***
<marler8997>
cross compiling on windows to something else, or to windows?
<marler8997>
pixelherdev, I was not aware of csmith...looks cool
<marler8997>
dlang had one that I think was pretty generic? dustmite
<marler8997>
lol
<marler8997>
if you're a boomer what does that make my 32 yo ass?
<marler8997>
argv.len?
<marler8997>
cool, I was able to use Xwayland to get doom over X to run on our printers that use wayland
<marler8997>
ifreund, how did it connect? does river have an XServer?
<marler8997>
none of it, all my '.so's are from my yocto repositories, none installed nativealy on the system
<marler8997>
looks like I don't have vulkan installed
<marler8997>
locate vulkan gives me 888 entries...lol
<marler8997>
dang, vulkan extension not present, my ubuntu probably too old
<TheLemonMan>
marler8997, what's this generic allocator thing?
<marler8997>
andrewrk, yeah that's a good idea
<andrewrk>
marler8997, yeah we should test the perf of your generic allocator with one that does its own tracking and see if we can use that to justify the interface
<marler8997>
this decision is what my generic allocator design addresses, it doesn't specify who owns allocation metadata, it can be managed by the caller or the allocator
<marler8997>
there are cases where an allocator could use it, however, I might argue that the use cases would be rare, and in the cases where it is useful, the allocator could manage that information itself
<marler8997>
I think the point of buf_align isn't to know the alignment of the pointer, but to be used in something like an alignment lookup table
<marler8997>
I should have a PR for LD_PRELOAD soon
<marler8997>
probably better to use LD_PRELOAD, then if we want, we can remove the values we added on the second invocation