* raz
takes off his monocle and rubs it ceremoniously with a little Fiber::Cloth
<raz>
ok, so i guess what i want is a #try with an else.
<jhass>
if current_user = self.current_user; else; end
<jhass>
current_user.try(&.delete) || show_error
<raz>
jhass: sadly not pretty. i need this kinda construct in view-related code (web framework) all the time
<jhass>
proeprty! ?
<raz>
i guess i'll rather avoid nil altogeter and invent a "NotAUser < User"
<jhass>
gives you current_user? and current_user
<jhass>
null object pattern is also fine, yeah
<raz>
oh, duh!
<jhass>
or getter! if you don't need the setter
<raz>
no, you just gave me the missing piece... must've had a brain-blockade
<raz>
of course i can just give my #current_user a #current_user? as a buddy
<raz>
and all my worries should dissipate
<raz>
i was just thinking too complicated
<raz>
thanks ;)
<jhass>
well the big difference to the approaches above or a null object is that you still risk runtime errors with that approach
<oprypin>
ye
<oprypin>
and for convenience note that `getter!` creates current_user (.not_nil!) and current_user?
<raz>
i think those are unavoidable (or rather: actually desirable) in my specific context
<raz>
it's a bit like that overflow debate you had on the forum
<jhass>
not sure I agree
<raz>
when my framework user tries to show `current_user.id` it but there is no user - i want it to blow up
<raz>
not show a blank id
<jhass>
the difference is in this case you can know beforehand if it would raise, you just may forget to check
<raz>
ah.. hmm
<jhass>
if overflow there's no so sane way to check if the operation would overflow before trying to do it
<raz>
but... the compiler can't know if user will be nil or not
<raz>
in some requests it is, in others it isn't
<jhass>
that's why it makes you check or assert it
<raz>
ahhh
<raz>
now i gotcha i think. with #current_user? my framework-user could still forget to actually call it
<jhass>
yeah
<oprypin>
raz, so pls just use `if (user = current_user?); stuff(user)`
<raz>
oprypin: i'm afraid that's not sustainable unless ameba could be taught to catch it
<oprypin>
what does ameba have to do with anything
<raz>
people will forget
<oprypin>
if the #1 language idiom is not sustainable then just reconsider all choices so far
<raz>
you mean starting from the language choice? :P
<oprypin>
i dont know why you say thnis. people will not forget because the object is nilable and the compiler will remind you
<raz>
hmm ah, ok, indeed, you win
<raz>
but it's still an ugly construct :/
<jhass>
I see you haven't written much Java :P
<raz>
when what you really want to write was a mere `current_user.id unless current_user.nil?`
<jhass>
for that line, still, current_user.try(&.id)
<raz>
jhass: yes i'm complaining on a very high level here. it's ugly by crystal standards. other languages would love if that was their biggest problem ;)
<raz>
hmm yap, i'll play around with these two options and almost certainly use them
<raz>
thanks for all the inputs!
v2px__ has joined #crystal-lang
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
<xyhuvud>
my take on this is that the language teaches you to avoid certain structures for things that can be nilable. That do trip newcomers over, but old farts have learnt how to write code where it doesn't become obnoxious
v2px__ has quit [Ping timeout: 260 seconds]
<xyhuvud>
It definitely have changed some ways I write ruby.
<Stephie>
oprypin, what happened to FronGitter
<oprypin>
oh damn
FromGitter has joined #crystal-lang
<oprypin>
at midnight it had to reconnect and then failed to authorize :|
<Stephie>
oof
<Stephie>
back online?
<Stephie>
okay yeha its working
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
sagax has quit [Excess Flood]
<FromGitter>
<watzon> @naqvis great work!
<FromGitter>
<vlazar> Oh wow! That is so cool!
<FromGitter>
<vlazar> Crystal would thrive with shards like these
<FromGitter>
<j8r> Ho, we can now have threads in Gitter
<FromGitter>
<j8r> TIL threads in Gitter :o
<FromGitter>
<j8r> I'm wondering how the IRC bridge will behave...
<FromGitter>
<vlazar> Who would have thought, right? I've TILed it a couple days ago here as well :)
<FromGitter>
<watzon> Yeah I just noticed that haha
<FromGitter>
<j8r> The thing I noticed is the `UNREAD` is buggy, however
<FromGitter>
<watzon> Definitely could be handled better
<FromGitter>
<oprypin> wow
<oprypin>
well it just shows messages unthreaded, which is as good as it can be
<oprypin>
this is perfect! now we just use gitter
<FromGitter>
<oprypin> haha it's buggy, if you scroll up high enough where the message would not have been visible normally, it will also error out in the thread
<FromGitter>
<straight-shoota> @naqvis Your HTML shards look really awesome. I've just this afternoon worked on a solution to resolve relative URLs in HTML source by hacking around libxml2. Might be much easier to do with your parser. Had I only known a few hours earlier... =)
<FromGitter>
<straight-shoota> Btw. I should have an old branch laying around for transforming CSS selectors into XPath. Maybe that could fit with your XPath shard
striking7 has joined #crystal-lang
<hightower2>
Hey I'm using the Pg module for the database.. is there any obvious reason why conn.execute("INSERT INTO tbl(col) VALUES (1)") would work just fine, but if I replaced "1" with ? and provided it as argument, it'd report syntax error at ")"?
<hightower2>
Like, conn.execute("INSERT INTO tbl(col) VALUES (?)", 1)
<hightower2>
Another issue, I do "INSERT INTO..." and I see that #exec returns me a DB::ExecResult. And there is property #last_insert_id on it, but it is always empty, regardless of whether I use "RETURNING id" in my INSERT query. Any hints?
<jhass>
try using a query
<jhass>
INSERT RETURNING is essentially a SELECT query in PG
<jhass>
in the wire protocol anyways
<hightower2>
mm yes, just found some issue for crystal-pg about it. Looks like query then, thanks
<FromGitter>
<straight-shoota> @Blacksmoke16 I'd expect Union(T) to match. Essentially, String can be considered a union of only a single type.
<FromGitter>
<Blacksmoke16> hmm
<FromGitter>
<Blacksmoke16> i suppose
DTZUZU has quit [Quit: WeeChat 2.7]
DTZUZU has joined #crystal-lang
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
DTZUZU has quit [Read error: Connection reset by peer]
DTZUZU has joined #crystal-lang
<hightower2>
straight-shoota: very nice, thanks!
<striking7>
Hey all. Brand new to Crystal, attracted by Lilith
<striking7>
I've gotten most everything to compile to build the disk image, but I'm getting this problem with mruby and libpng
<striking7>
lilith/lilith/pkgs/.build/libpng-1.6.37/png.c:302: undefined reference to `setjmp'
<striking7>
So of course wm and anything else that wants libpng won't work either.
<striking7>
Anyone ever get that? Cross-compile toolchain thing perhaps?
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
v2px__ has joined #crystal-lang
<FromGitter>
<Blacksmoke16> :shrug: sorry
<FromGitter>
<watzon> I haven't really played with lilith funny enough. I don't find Crystal to be the best OS language. I did do my own x86 projects in Zig and Nim though.
HumanG33k has joined #crystal-lang
<striking7>
NP, Blacksmoke. Watzon: I don't know if it is either, but I was fascinated how quickly this language came from nowhere and made progress like that. Intruiged me for sure.
<striking7>
My career path has rarely taken me into operating systems, so they remain a fun topic for me to mess with
<striking7>
And I adore Ruby, but C++ is my favorite for its static tracability. Crystal may be on to something. I'll keep an eye on it
<FromGitter>
<watzon> Tbh I would love to have a sub/superset of Crystal that's a bit more focused on lower level programming. Manual memory management using allocators or something is really the only thing I can think of that would really be necessary.
striking7 has quit [Ping timeout: 246 seconds]
_ht has quit [Remote host closed the connection]
<FromGitter>
<straight-shoota> @watzon you *can* do manual memory management in Crystal. It's just that the stdlib doesn't...
<FromGitter>
<watzon> Well yeah, that's more so the point I guess. Crystal isn't really built for manual memory management. It would be interesting if, somewhat like nim, manual memory management were possible but not mandatory.
<FromGitter>
<Blacksmoke16> > manual memory management were possible but not mandatory ⏎ ⏎ Isnt this what @straight-shoota is saying? That you *can* do it, just the stdlib doesn't
<FromGitter>
<watzon> Well technically yes I suppose haha, but having to completely rewrite the parts of the standard library that you want to use makes manual memory management impractical.
<straight-shoota>
indeed
<straight-shoota>
but we can't have a stdlib that's either manual or automatic memory management depending on what you want
<FromGitter>
<watzon> Also fair. One reason I kind of like the Nim approach. They have different garbage collectors you can use, or you can use no GC in which case you have to basically implement your own. Idk if or how something like that would work with an LLVM language like Crystal, but it would be an interesting option.
<FromGitter>
<watzon> Or like I said, having a superset of Crystal that does manual memory management with allocators or something would be interesting, but a pretty massive undertaking
<FromGitter>
<Blacksmoke16> `-Dgc_none`
<FromGitter>
<watzon> May as well be `-Dstdlib_none` haha
<FromGitter>
<Blacksmoke16> can do that too, `--prelude=none`
<FromGitter>
<Blacksmoke16> or something like that