ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
Ichorio has quit [Read error: Connection reset by peer]
hoppetosse has quit [Ping timeout: 260 seconds]
sagecode has quit [Ping timeout: 264 seconds]
sagecode has joined #zig
quc has quit [Ping timeout: 245 seconds]
hoppetosse has joined #zig
meena has quit [Read error: Connection reset by peer]
meena has joined #zig
hoppetosse has quit [Remote host closed the connection]
isd has quit [Ping timeout: 260 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sagecode has quit [Ping timeout: 264 seconds]
donlzx has joined #zig
isd has joined #zig
meena has quit [Read error: Connection reset by peer]
meena has joined #zig
<GitHub141>
[zig] andrewrk opened pull request #1109: allow passing by non-copying value (master...pass-by-non-copying-value) https://git.io/vh6oi
bheads has quit [Quit: Leaving]
isd has quit [Ping timeout: 264 seconds]
isd has joined #zig
dbandstra has joined #zig
darithorn has quit [Remote host closed the connection]
Richard has joined #zig
Richard is now known as Guest1549
Guest1549 has quit [Client Quit]
very-mediocre has joined #zig
davr0s has joined #zig
alexnask has joined #zig
<dbandstra>
why is there no u1 type?
xtreak has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
xtreak has quit [Remote host closed the connection]
<alexnask>
@dbandstra I thought there was.. You can do 'const u1 = @IntType(false, 1)' though
<alexnask>
Do < 8 bit types in a packed struct behave like bitfields btw? Haven't really tested out
<andrewrk>
alexnask, yes they do and bools are 1 bit in a packed struct
<alexnask>
Rgiht, makes sense, much more elegant than having a language construct
<alexnask>
I'll work on some @typeInfo bug fixes and improvements
<alexnask>
I may take a stab at removing @typeId too
<andrewrk>
alexnask, I think we should treat generic functions differently than normal functions
<andrewrk>
people keep trying to look at the types of generic function args, and it doesn't make sense
<alexnask>
Right, I was pretty surprised at how zig treated them interanlly myself
<andrewrk>
I'm not sure we want to reveal the fn(var, var) -> var thing that the compiler uses internally
<alexnask>
Hmm
<alexnask>
We should still expose the arg types up until the first type erased arg right?
<andrewrk>
is there a reason to?
<alexnask>
One example I can think of is checking to see wether a method takes a *const Self (or Self now, I guess) first parameter
<andrewrk>
yeah alright. maybe status quo is not so bad
<alexnask>
If we give no arg type info at all for generic fucntions
<alexnask>
I mean, I do think it's an issue for sure
<alexnask>
I'm just not 100% on what the correct way to approach it is
<alexnask>
My original plan was to use a ?type field in the FnArg
very-mediocre has joined #zig
<alexnask>
And null would mean we have no type information, aka this is a type erased argument
<alexnask>
(which is what I do but with @typeOf(undefined) atm)
<alexnask>
I think the surprise factor is that everything after the first generic argument is type erased
<alexnask>
Not so much that the generic argument itself has no type, I guess
<alexnask>
I think the sanest solution would be to change compiler internals to keep argument types and the return type if we know it and only type erase the generic arguments, but I do get this would be a huge amount of work
<andrewrk>
that would introduce the concept of testing if something compiles
very-mediocre has quit [Ping timeout: 260 seconds]
<andrewrk>
it would make Pavel Vozenilek so very, very happy
<andrewrk>
I don't think it's a good idea
isd has quit [Quit: Leaving.]
<andrewrk>
type expressions are evaluated with the previous args in scope, so after the first `var` we can't know the types anymore, by definition
<alexnask>
I don't get why this is the case, I guess I
<alexnask>
I'll have to dig in the source code*
<andrewrk>
so you can do @typeOf(prev_arg)
very-mediocre has joined #zig
<alexnask>
Right, I get why we would evaluate type expressions with the previous args in scope
<alexnask>
But if we do get a generic argument followed by, say, a u8 argument, why would we be unable to resolve u8 when it does not depend on any previous argument?
<alexnask>
I guess this would require testing wether a type expression depends on the previous arguments which would be a bit of a mess
<andrewrk>
I guess we can support this if it makes sense
<andrewrk>
I don't know why zig users are so obsessed with metaprogramming :)
<alexnask>
Mmm that sweet sweet comptime just makes everyone wanna do it :P
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
JinShil has joined #zig
alexnask_ has joined #zig
dbandstra has quit [Quit: Leaving]
xtreak has joined #zig
alexnask has quit [Ping timeout: 255 seconds]
alexnask_ is now known as alexnask
ssf has joined #zig
quc has joined #zig
fcambus has joined #zig
davr0s has joined #zig
ManDeJan has quit [Ping timeout: 276 seconds]
<alexnask>
Did the way C include paths are inferred change? I'm getting some weird errors on cImports
ManDeJan has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
ManDeJan has quit [Ping timeout: 256 seconds]
<alexnask>
@andrewrk ?type still fails btw, optionals need a di_type atm.
ManDeJan has joined #zig
ManDeJan has quit [Ping timeout: 240 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ManDeJan has joined #zig
ManDeJan_ has joined #zig
ManDeJan has left #zig ["Leaving"]
ManDeJan_ has quit [Client Quit]
<GitHub42>
[zig] alexnask opened pull request #1110: Enabled optional types of zero bit types with no LLVM DI type. (master...optional_type) https://git.io/vh69m
ManDeJan has joined #zig
ManDeJan has left #zig [#zig]
<alexnask>
Turns out this would probably have worked without pointer reform :P
ManDeJan has joined #zig
davr0s has joined #zig
mahmudov has quit [Ping timeout: 256 seconds]
mahmudov has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
xtreak has quit [Ping timeout: 256 seconds]
JinShil has quit [Quit: Leaving]
mahmudov has quit [Ping timeout: 245 seconds]
mahmudov has joined #zig
xtreak has joined #zig
<alexnask>
Turns out this would probably have worked without pointer reform :P
<alexnask>
woop
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<very-mediocre>
The latest change with passing a struct as a function param seems a bit magical
<very-mediocre>
shouldn't it be explicit whether a copy or pointer is used?
<very-mediocre>
Say it quietly ends up being a pointer and the object gets modified elsewhere...
<very-mediocre>
If you're ok with that you'd make it a pointer, if you're not OK with it, you'd attempt to pass by value, so it seems a bit counterintuitive
<very-mediocre>
correct me if i'm wrong
<alexnask>
There isn't any way to pass aggregate types by value/copy, even know
<alexnask>
now*
<very-mediocre>
I'm aware but I'm saying: shouldn't there be?
<alexnask>
Well, you can explicitly copy your object then pass it in I guess
<very-mediocre>
because if you intentionally decide not to pass a pointer, and it ends up being a pointer anyway, that feels a bit magical
<alexnask>
I do agree it's a bit weird
noonien has joined #zig
<alexnask>
@very-mediocre I don't personally think it's too much magic, it's just another way of thinking about by-value arguments
<alexnask>
What you get is an immutable 'view' to the value
<alexnask>
Whatever way is faster (by copy for small structs, by reference for bigger ones)
<very-mediocre>
yeah i get it, just kind of mulling it over wrt. user experience (as a user of course, I don't want to create a peanut gallery dynamic)
<alexnask>
If you need to guarantee a copy is passed, it is still apparent at the call site instead of the func declaration
<alexnask>
I'm not 100% sold on it either, I guess we have to see how it plays out in real code
<alexnask>
I do think it's what you want to do 90% of the time though, think of all the const refs in C++ code
<very-mediocre>
true
<alexnask>
And the issue there is that you may have a small struct (say <= 64 bits) so you use by value semantics but if you add a couple of fields you then need to switch up to const refs everywhere
<alexnask>
(128 bits is probably more realistic but you get the idea)
<very-mediocre>
yeah
<alexnask>
The syntax will be confusing to people coming from C and C++ though (which will probably think we are all bad systems programmers since it appears we pass everything around by value :P)
fcambus has left #zig [#zig]
very-mediocre has quit [Ping timeout: 260 seconds]
davr0s has joined #zig
alexnask has quit [Read error: Connection reset by peer]
alexnask has joined #zig
very-mediocre has joined #zig
<very-mediocre>
lol.
<very-mediocre>
I feel OCD about micromanaging this and passing pointers explicitly when needed
<very-mediocre>
maybe I'm not zen enough
<alexnask>
I can't think of any usecase where explicitely requiring a pointer is needed
<very-mediocre>
I know, it's just OCD
<alexnask>
Unless you need to forward the pointer and have it escape the function scope, but that would be a compiler error with escape analysis
<alexnask>
:p
<very-mediocre>
like if it's a large struct I feel I want to pass a pointer
<very-mediocre>
if I don't that feels wrong
<alexnask>
2998 commits, who will get the #3000
<alexnask>
I'm rooting for my PR :P
<alexnask>
Pretty excited for noalias by default though, will zig be the only language to beat Fortran in perf? :D
<very-mediocre>
everything about zig is exciting
<very-mediocre>
that's why i'm hanging out here :)
<very-mediocre>
I was waiting for something like zig for a while now
<very-mediocre>
in its current state you can already tell it's going to be a winner
<alexnask>
Are you mainly excited about the metaprogramming aspects or the "modern C" aspects?
<very-mediocre>
for me it's modern C"
<alexnask>
I think we should have a survey, seems like many metaprogramming junkies hang out in here :P
<very-mediocre>
but also getting as close as possible to Rust's safety by default
<very-mediocre>
without compromising usability
<very-mediocre>
that's something that C sorely needs
<alexnask>
Right, the only aspect that is kind of disappointing to me is the lack of some "automatic" memory/resource handling
<very-mediocre>
lack of GC is a big draw for me actually
<alexnask>
I dont necessarily mean GC, I do agree with that
<very-mediocre>
99% of modern languages use GC
<alexnask>
Like some kind of RAII
<very-mediocre>
yeah, actually I could go for a bit of OOP
<very-mediocre>
at the risk of sounding crazy
<very-mediocre>
just a biiiit more
<alexnask>
Pls no inheritance :p
<alexnask>
Most OO features can be implmented with some metaprogramming
<alexnask>
Right, I don't like the idiomatic interface model the standard library uses
<very-mediocre>
that compile time interface implementation is cool but I'm too nooby to grasp it at the moment, I've not gone into zig compile time in any depth yet
<very-mediocre>
It's doing composition instead of inheritance
<alexnask>
The test block is the important part ^^
<very-mediocre>
like iirc FileStream has a general IOStream as a property
xtreak has quit [Ping timeout: 240 seconds]
<very-mediocre>
and iirc the `init` function maps the inner stream to the outer api
<alexnask>
Yes, this is the biggest weakness in my opinion too, the implementation type has to include the interface type
<alexnask>
Instead of wrapping the implementation object + vtable pointer into the interface and writing the implementation types in complete isolation
<very-mediocre>
It almost feels like `goto` sometimes tracking down each inner "interface" property
<very-mediocre>
hard to read
<very-mediocre>
yeah, I've heard traits are on the table
<alexnask>
This was the main motivation behind my interface implementation
<alexnask>
(it's basically traits in userspace)
<very-mediocre>
yeah, looks good as a proof of concept
<alexnask>
I don't mind having them as a language feature but I do think its kind of a shamew
<alexnask>
The metaprogramming features are so strong you can basically write it in userspace, and that is more flexible imho (each library can use its own model while being compatible with types written in other libraries/by the user)
<very-mediocre>
Getting C++ wild west flashbacks
<very-mediocre>
I'm pretty sure this situation will improve in zig
<very-mediocre>
I don't think it's set in stone
<alexnask>
Right, we are really early in development
<very-mediocre>
re: metaprogramming - I have very mixed feelings about it
<very-mediocre>
at some point it degrades into the wild west
<very-mediocre>
not quite metaprogramming but a similar degradation = javascript ecosystem
<very-mediocre>
lots of hodge podge solutions
<very-mediocre>
every library uses a different convention
<very-mediocre>
I dread the idea of every zig library rolling its own OOP
<alexnask>
Hmm
<alexnask>
Right, I think there should be reasonable defaults provided in the standard library
<alexnask>
It's just a pet peeve of mine that language features should not be used when you can accomplish the same thing (or something reasonably close and useful) using the features already available
<very-mediocre>
well it's a balance
<alexnask>
Ofc this is subjective
<very-mediocre>
fortunately zig has a strong vision that will ignore the peanut gallery (=me) if needed
<very-mediocre>
i'm glad it's not designed by committee
<very-mediocre>
andrewrk has proven himself, the language is at 0.2.x and is already getting hyped
<alexnask>
I completely agree, andrewrk is doing a great job imho, if he just accepted every issue we would have a zig++ situation by now for sure :P
<very-mediocre>
It's good he doesn't feel bad about saying "no"
<very-mediocre>
If I discuss the language here my goal is just to provide unfiltered ideas
<alexnask>
Tbh the language feels pretty complete, we just need ergonomics imporvements
<very-mediocre>
I have no expectation that anything I say will be taken on board
<very-mediocre>
yeah
<alexnask>
And a couple of features like tuples (since varargs are going to be removed) and some sane closure/lambda system
<very-mediocre>
tuples feel loose to me
<very-mediocre>
feels like they break the type system
<very-mediocre>
var my_thing = function_that_can_return_2_types_of_tuples()
<very-mediocre>
what is my_thing's type?
<very-mediocre>
had a chat about that here the other day
<alexnask>
Well, this is an "issue" with any type, not just tuples right?
<alexnask>
If the function is generic, that is
<very-mediocre>
it's an issue with multiple return types
<very-mediocre>
oh at comptime it's not an issue
<very-mediocre>
since you have to provide T as a param
<very-mediocre>
the problem is tuples have runtime polymorphism
<alexnask>
Waat
<very-mediocre>
a generic function is called with T
<alexnask>
I thought the tuples would basically be record types/anonymous structs
<very-mediocre>
so you know it returns T
<very-mediocre>
polymorphism is the correct word but I think you took it in an OOP context
<very-mediocre>
consider: fn whatever(T: type): T
<alexnask>
Right
<very-mediocre>
var my_var = whatever(u8)
<very-mediocre>
you know my_var is u8
<alexnask>
Sure
<very-mediocre>
but if whatever returns a tuple
<very-mediocre>
maybe it has 2 fields, maybe 5
<very-mediocre>
who knows
<alexnask>
I don't think that's how the tuple proposal works
<very-mediocre>
var my_var = fn whatever() -> return tuple with unknown fields
<alexnask>
The tuple fields must be known at compile time
<very-mediocre>
sure but I read a comment that the same function could return several types of tuples
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask>
That can only happen based on the comptime parameters you pass to the function
<very-mediocre>
great then
<alexnask>
fn foo(comptime a: var, comptime b: var) some_tuple_type(a, b) { ... }
<very-mediocre>
I thought this would be a runtime thing
<very-mediocre>
if it's just anonymous structs, then great
<alexnask>
No, I'm 90% sure they will just be record types
<very-mediocre>
how do you distinguish between that and an anonymous struct
<alexnask>
I dont even see how they could be runtime polymorphic without some kind of allocation and runtime type representation
<alexnask>
I mean anonymous struct, idk if record type is correct in this context
<very-mediocre>
exactly, that's why I was going over it, but I think I got the wrong impression about the multiple return types
<alexnask>
:p
<very-mediocre>
that's why I was concerned about it
<very-mediocre>
like if that was the case, then if you did var some_var = whatever();
<very-mediocre>
the type of var would have to be "tuple"
<very-mediocre>
which is meaningless
<very-mediocre>
but you couldn't infer anything other than it's some random structure
<very-mediocre>
i'm glad I misunderstood that comment
<alexnask>
Right, I agree that would be horrible :P
<alexnask>
The current proposal is basically a way to get rid of varargs and give us some way to make anonymous structs
<alexnask>
Although we could keep varargs, fix them at comptime and write tuples in userspace (jk, jk)
<very-mediocre>
we spent a longgg time talking about returning different kinds of tuples at runtime
<very-mediocre>
I thought I missed something, like "why is that on the table"
alexnask has quit [Ping timeout: 260 seconds]
<lqd>
alexnask: I think what you're referring to as "rust traits" are "rust trait objects", the traits are the typeclasses, the trait objects are the "pointer to data and vtable"
xtreak_ has quit [Ping timeout: 240 seconds]
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
xtreak has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
bheads__ has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
bheads_ has quit [Ping timeout: 240 seconds]
donlzx has quit [Quit: Leaving]
very-mediocre has joined #zig
sagecode has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
mahmudov has quit [Remote host closed the connection]
davr0s has joined #zig
very-mediocre has joined #zig
richard has joined #zig
richard is now known as Guest15893
Guest15893 has quit [Ping timeout: 260 seconds]
<bheads__>
alexnask very-mediocre anderwrk, I really just want to use metaprogramming as a why to provide an interface/concepts/traits via duck typing.
<bheads__>
I would also like to use it for serializers as well
xtreak has quit []
<bheads__>
but I am 100% to other solutions to these problems :)
<bheads__>
100% open to other***
<bheads__>
Things like streams and interators (ranges) and Allocators should be an interface. Not digging the composition and function pointers.
<bheads__>
just my thoughts, beyond that I really like zig
<very-mediocre>
I agree that a lightweight layer of OOP improvements would be awesome
<very-mediocre>
whether it's interfaces or traits or something else, I don't know
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
clownpriest has joined #zig
<clownpriest>
is there any plan to introduce attribute tags?
<clownpriest>
for example, #[inline(always)] specifier for a function
<clownpriest>
so you can avoid doing @inlineCall() on each invocation
<Hejsil>
This would allow: fn<.Extern> a() void {}
<Hejsil>
Less heavy :)
<bheads__>
That is a good approach, cause someone cause and write a gcc based zig compiler and have other supported calling conventions
<bheads__>
someone could*** man I need more coffee
<clownpriest>
you know that feeling where you've had so much coffee that your heart's racing, but you're still completely sleepy and exhausted? feels like this is going to be one of those days for me
<clownpriest>
also, did andrewrk do a live coding stream this morning?
<bheads__>
dont think so, nothing on his twitter
Hejsil has quit [Quit: Page closed]
zignoob has joined #zig
zignoob_ has joined #zig
zignoob_ has quit [Quit: leaving]
zignoob has quit [Ping timeout: 260 seconds]
zignoob_ has joined #zig
zignoob_ has quit [Quit: Lost terminal]
<andrewrk>
very-mediocre, > what is my_thing's type?
<andrewrk>
here's an example tuple type from the proposal: tuple { i32, f32 }
<andrewrk>
it's essentially a struct with no field names. tuples have comptime known length and types, and runtime known values, same as structs
<very-mediocre>
👍
<very-mediocre>
alexnask explained it to me earlier
<very-mediocre>
when we were talking about tuples a couple of days ago I was hung up on "how could this work" with the assumption it was at runtime, not comptime known
<very-mediocre>
very reassured with the actual proposal :)
<andrewrk>
clownpriest, we already have inline for functions and it guarantees inlining. we also have @inlineCall to guarantee inlining at a callsite and @noInlineCall to guarantee not inlining at a callsite
mahmudov has quit [Ping timeout: 248 seconds]
mahmudov has joined #zig
<bheads__>
you can inline at the impl side of a function?
<andrewrk>
yes
<bheads__>
nice, guess its just missing in docs
<bheads__>
ah found it "FnDef = option("inline" | "export") FnProto Block"
<GitHub75>
zig/master 4ec09ac Alexandros Naskos: Enabled optional types of zero bit types with no LLVM DI type. (#1110)...
<GitHub194>
[zig] andrewrk closed pull request #1110: Enabled optional types of zero bit types with no LLVM DI type. (master...optional_type) https://git.io/vh69m
<andrewrk>
bheads__, I should probably documented it somewhere in addition to the grammar rules :)
<bheads__>
true, but it is in the docs :)
bheads_ has joined #zig
ssf has quit [Ping timeout: 260 seconds]
alexnask has joined #zig
bheads__ has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ManDeJan has quit [Ping timeout: 240 seconds]
<andrewrk>
oh wow. somebody did work on the mach-o linker in lld trunk
pianofingers has joined #zig
<pianofingers>
This might be jumping the gun by a few years, but has there been any discussion on eventually supporting the language server protocol?
<pianofingers>
btw I'm extremely pleased to hear about guaranteed inlined functions!
dbandstra2 has joined #zig
<dbandstra2>
alexnask: can you update your interface.zig gist to the latest zig syntax? i'm not familiar with all the changes that happened in the last month. i'd like to check your thing out
<MajorLag1>
Am I the only one that feels like a dangling `@tag()`, regardless of pre/postfix, looks strange and un-ziglike? All the other builtin functions look and act like functions, so I feel like `@tag()` should too.
noonien has quit [Quit: Connection closed for inactivity]
Hejsil has joined #zig
<Hejsil>
MajorLag1, agreed. It's not really in the style of the other builtins
<alexnask>
@<struct literal> could be an alternative, like @{ .attr=value() }
<GitHub33>
zig/master cdf1e36 Andrew Kelley: fix build on windows, broken by previous commit
<MajorLag1>
I still prefer my way (naturally), where it is part of the type: `field: @tag(T, Whatever),`. Though that raises issues about casting and inferrence I suppose.
<MajorLag1>
but it also lets you reuse a set of tags over a lot of fields.
<MajorLag1>
hmm... actually, I can make that work right now with a comptime generated struct, but the field won't implicitly cast to the base type so accessing it gets a bit getter/setter-y.
<MajorLag1>
Yet another way to implement tag functionality in userspace though.
<MajorLag1>
andrewrk, are null terminated pointers on the short list? I'm trying to determine if I should pause my current projects and catch up with the language changes or wait until that's in.
<bheads_>
MajorLag1, that could be solved with "use" in a struct that brings a field in scope, ie: struct { wrapped_thing: T, use wrapped_thing; ... };
very-mediocre has quit [Ping timeout: 260 seconds]
<MajorLag1>
When I first read that 'remove explicit casting' proposal I had a pretty negative reaction to it, but it's grown on me. Could we also use it to specify behavior like `var x = @intClamp(u8, some_u16)`? Saves some code in a relatively common case without being harder to read.
<andrewrk>
that sounds like @truncate
<andrewrk>
I don't understand your question - what's the proposed change?
<andrewrk>
so the idea of that proposal is that you wouldn't be able to do u8(some_u16) - you would have to use either @truncate or @intShorten
bheads__ has joined #zig
alexnask has quit [Quit: Leaving]
alexnask has joined #zig
bheads_ has quit [Ping timeout: 264 seconds]
<GitHub76>
[zig] bnoordhuis opened pull request #1112: add cross compilation regression test (master...wasm-smoke-test) https://git.io/vhPlZ
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sagecode has quit [Ping timeout: 240 seconds]
<MajorLag1>
andrewrk, you're right, it is @truncate, I wasn't thinking it through.
<MajorLag1>
No wait, @truncate always truncates the significant bits.
<MajorLag1>
So @truncate(u8, u16(0xFF00)) == 0x00, but my thought with @intClamp was that @intClamp(u8, u16(0xFF00)) == 0xFF and @intClamp(i8(-1)) == 0x00. But really, if that sort of thing happens a lot it should probably be done in an inline fn, so nevermind.
<andrewrk>
I think that would be @truncate(u8, value >> 8)
<andrewrk>
potentially wrapped in a userland function
<MajorLag1>
yeah, that works
<MajorLag1>
point is, I wasn't thinking it through.