<FromGitter>
<asterite> @funny-falcon There's no way right now. The access is there so that to implement `Struct#==` or other similar operators you can access instance variables directly without requiring the type to define a method
<FromGitter>
<asterite> I know it sounds ugly or like a hack. But remember that anyone can reopen any type in Crystal, and so if you have a type with instance variable @x I can always reopen it and define `def x; @x; end` to access it
<FromGitter>
<asterite> so even if we remove `x.@y` from the language anyone can "hack" your type
<FromGitter>
<funny-falcon> So that, why there are visibility modifiers at all?
<FromGitter>
<funny-falcon> Just API declaration?
<FromGitter>
<funny-falcon> ie these methods will be useful for you, those methods better not to be used (but certainly you can).
<FromGitter>
<funny-falcon> Ah, never mind. I forget that Ruby on a same plane.
<gcds>
C++ Life: U create a simple template class name it for e.g. Buffer everything is fine and etc. now u want to change to more appropriate name CircularBuffer guess what happens freaking pile of errors change back everything works... I am sitting here like wtf... I just do simple Find & Replace :D
<RickHull>
what is the most popular IDE for C++ on unixlikes? I assume VisualStudio otherwise
<RickHull>
this seems like something an IDE would tackle
<gcds>
CLion
<gcds>
tried refactor
<gcds>
every freaking name apart CircularBuffer works
<gcds>
I speachless...
snsei has quit [Remote host closed the connection]
_whitelogger has joined #crystal-lang
<FromGitter>
<faultyserver> might be a stupid question, but what's the best way to write specs about the output of a program
<FromGitter>
<faultyserver> either to STDOUT or STDERR
<FromGitter>
<faultyserver> should I just stub them with `IO::Memory`s?
<FromGitter>
<maiha_twitter> Hi! This works in 0.23.x, but failed in current master. Is this known issue? Or, need to create an issue on github? ⏎ ⏎ ```class Foo(T) ⏎ alias List = Array(T) ⏎ end``` [https://gitter.im/crystal-lang/crystal?at=59eaf47c614889d475e071f3]
<oprypin>
faultyserver, yes, don't interact with real streams in a unittest. provide a general API that can work on any IO. or do this hack https://github.com/mosop/stdio
<crystal-gh>
[crystal] MakeNowJust opened pull request #5158: Fix to complete filename for `crystal tool` subcommands (master...fix/completion/complete-filename-tool) https://git.io/vdbyx
<jsn->
it's somewhat surprising that there seems to be no htonl/htons/etc in the library, though
<RX14>
jsn-, the most common reason for conerting endianness is for transmission
<RX14>
converting*
<RX14>
and byteformat covers that
<jsn->
RX14, yeah, i get that, that's what i used
<RX14>
i mean IO::Memory is my favourite way
<FromGitter>
<Papierkorb> There's `IO::ByteFormat.decode(x, IO::ByteFormat::NetworkEndian`. If that's too verbose for you (It's quite long, ok), just write a local helpe rmehod
<RX14>
just io.read(Type, Endinaness)
<RX14>
or write
<FromGitter>
<Papierkorb> ^ If you have an IO anyway
<FromGitter>
<Rinkana> @jsn yeah thats what i needed
<FromGitter>
<Rinkana> `IO::ByteFormat::LittleEndian.decode(Int32, header[0x12, 0x16])` works
<RX14>
@Rinkana where is this data from?
<FromGitter>
<Rinkana> BMP image file
<RX14>
so surely an IO
<RX14>
except sometimes that IO is represented in memory
<RX14>
using IO::memory
<RX14>
i won't make you change your architecture but i'd have written my code around streaming input first
<RX14>
then just used IO::Memory for the case where you get a buffer
<FromGitter>
<Rinkana> I pass an file object
<FromGitter>
<Rinkana> And that gets parsed into the correct format
<RX14>
a file is an IO...
<FromGitter>
<Rinkana> This is for reading the header (width, height)
<FromGitter>
<Rinkana> Yeah
<RX14>
so why a byte array
<RX14>
instead of reading from the IO
<RX14>
it's much cleaner
<FromGitter>
<Rinkana> Well, i tought it would be better this way. So i can reference the header locations themselfs.
<FromGitter>
<Rinkana> But what method would you reccomend from the file IO to use
<FromGitter>
<Rinkana> I know the byte locations (0x12 and 0x16)
<RX14>
start with an IO at the start of the header
<RX14>
and read off the fields in order
<RX14>
oops
<RX14>
thats io.read_bytes
<RX14>
not io.read
<RX14>
there's write_bytes too
<RX14>
they're well documented
<FromGitter>
<Rinkana> Alright
<FromGitter>
<Rinkana> I'll look into that
<jsn->
for example, from something like pcap or even a udp socket, you get a packet as one memory block; it would be nice if one could just convert *some* of the fields to host format in place, without touching the rest
<RX14>
jsn-, well the IO::ByteFormat stuff exists for that
<RX14>
you could do it just file with IO::Memory and pos=
<jsn->
yeah, but that's a bit tedious
<RX14>
sure
<FromGitter>
<Papierkorb> Or `Cannon::FastAuto` *runs*
<RX14>
but it's much less common that IO::ByteFormat servers itself well
<RX14>
@Papierkorb just the name screams "too much magic" to me
<FromGitter>
<Papierkorb> RX14, in reality, it really just adds a "marker" method
<FromGitter>
<Papierkorb> Well I don't guarantee the memory format in cannon, so it's actually an implementation detail that it would work. You shouldn't rely on it™
<FromGitter>
<Rinkana> I do need to use `IO::ByteFormat::SystemEndian`
<FromGitter>
<Rinkana> As `NetworkEndian` is wrong
<jsn->
if I want to monkey patch e.g. Int32 to have #htonl, should I use ByteFormat? will it be fast?
<RX14>
use LittleEndian then
<RX14>
SystemEndian is platform-specific
<RX14>
jsn-, it should eb fast
<FromGitter>
<Papierkorb> @Rinkana, you can always use helper methods: `def read_many(io, endian, *types); types.map{|t| io.read_bytes(t, endian)}; end`
<jsn->
[as fast as e.g. xchg %ah, %al, ideally? :)]
<FromGitter>
<Papierkorb> LLVM can do that, yes
<RX14>
check the assembly if you want
<jsn->
even though ByteFormat requires a memory location to work with? that would be interesting, perhaps I'll look at that sometime
<RX14>
well
<FromGitter>
<Rinkana> Stefan, that's a handy method. Thanks!
<RX14>
jsn-, yeah it does require a memory location
<RX14>
but it's as fast as a read and then xchg likely
<RX14>
well hopefully
<RX14>
we place a lot of trust in llvm here lol
<RX14>
we can always optimize them later in assembly or something
<FromGitter>
<Papierkorb> It's just a memory dereference
<FromGitter>
<Papierkorb> LLVM can do that I think
<RX14>
its a memcpy to a stack buffer
<RX14>
then a reverse
<FromGitter>
<Papierkorb> Oh that part you mean
<RX14>
and then defererence that pointer as an int
<RX14>
the question is whether it can elide the memory copy and stack buffer entirely
<RX14>
the answer is to stick it in a loop
<RX14>
and profile it
<FromGitter>
<Papierkorb> well memcpy/memset are pretty famously messed with by optimizers
<FromGitter>
<maiha_twitter> Yup. But it's too pain when we need it in many places without alias.
<FromGitter>
<maiha_twitter> For instance, such a complex case `Proc(T, Hash(T, Array(T)))`. We must type this in all places in master branch.
ishahnaz has quit []
<FromGitter>
<Papierkorb> oprypin, your issue comment formatting is broken
<FromGitter>
<Rinkana> Is there a maximum amount of bytes i can read at once? Small batches return the correct values. But when i want to read 262144 bytes the whole bytearray is only zero's
<FromGitter>
<Rinkana> Argh
<FromGitter>
<Papierkorb> @Rinkana, you shold be able to read (in practice) any sized buffer at once.
<FromGitter>
<Rinkana> Yeah, there was just a huge chunk of zero's in the file......
<FromGitter>
<bew> But maybe that was before he actually tried it
rohitpaulk has joined #crystal-lang
<FromGitter>
<monouser7dig> I have an Object and when this object is created I want certain other objects to be created as well, how would I do that? at first I wanted to store the decency objects in a hash with their name and how many I need them but...
<FromGitter>
<Rinkana> Alright, this is getting weird
<FromGitter>
<Rinkana> It seems that read only returns some of the bytes. And zero's the rest
<FromGitter>
<bew> It's unlikely to do that, what are you doing?
<FromGitter>
<Rinkana> It will read 8137 bytes, and the rest are zero's
<FromGitter>
<Rinkana> I have a BMP file, and i'm reading all the data bytes
<FromGitter>
<Rinkana> `hexdump -C -n500000 image.bmp` shows me that there should be bytes there
<oprypin>
RX14, i was sleepy so i didn't really comprehend it, also i kinda don't care anymore
<RX14>
basically just use modules in Crystal::System and include them into IO::FileDescriptor
<RX14>
instead of reopening
<RX14>
and instead of creating a useless FileHandle
<oprypin>
that's quite nice. though not sure if it would leak into documentation
<Papierkorb>
lgtm
<RX14>
yeah oprypin i think we'd need to make it's methods private
<oprypin>
i don't quite get why lightly platform-specific need a heavier approach
<RX14>
it's not heavier
<RX14>
it's more explicit
<RX14>
which makes the non-platform-specific stuff much more readable
<RX14>
you never look at a method and wonder "where did this come from"
<RX14>
as it's prefixed with Crystal::System
<RX14>
in larger classes like IO::FileDescriptor it's going to be messy either way
<RX14>
and at least this way we have the xplicitness of an include statement
<oprypin>
i think that sometimes using Crystal::System is worse than always using Crystal::System
<RX14>
well this is still using crystal::system
<RX14>
and I disagree anyway
<RX14>
perhaps it's just easier to make IO::FileDescriptor hell
<Papierkorb>
Platform specific module/struct/class implementations (of same name) in Crystal::System for everything platform specific might be the easiest to explain later on.
<RX14>
well
<RX14>
we need to do something
<RX14>
just merging the dual-file hack from the original PR is too bad
<Papierkorb>
also to make it explicit that the code of the stdlib class is now about to do something platform specific. If you then later on want to add something new, it's clearer where things should end up
<oprypin>
nothing beats Errno though
<RX14>
and just sitting here bikeshedding isn't getting anything done
rohitpaulk has joined #crystal-lang
<RX14>
Errno is the ultimate hack
<oprypin>
btw remember me mentioning making OSError a module
<RX14>
"just do what C does but oh lets embed it in a proper exception hierarchy so it looks out of place lol"
<oprypin>
that cannot work because the module cant store the error code in it and you cant have the fallback error that i was harping about
<oprypin>
monouser7dig, I think you are doing something invalid but the error message should be different
<oprypin>
class variables are not shared to subclasses
<oprypin>
it should be telling you unknown class variable because you never define it in the class but use it
<oprypin>
nvm
<FromGitter>
<monouser7dig> doc says "Class variables are inherited by subclasses with this meaning: their type is the same, but each class has a different runtime value. For example:" as I understand it the subclass has the same variable with a separate value
<oprypin>
monouser7dig, what's really happening is that, ignoring the base class, the compiler concludes that @@x would be nillable. so it ends up as the type `Int32 | Nil`. and conflicts with the base class.
<RX14>
its a bug surely
<oprypin>
yes
<FromGitter>
<monouser7dig> so how do I have a var in a superclass and overwrite it in a subclass? just not?
<oprypin>
monouser7dig, just add @@x = 0 in the subclass as well
<oprypin>
i hypothesize that assigning the class variable anywhere in the subclass makes the compiler forget all information about it from the parent class
<oprypin>
except for that conflict check
<FromGitter>
<bew> It doesn't forget the type
<oprypin>
it forgets the type. it remembers it only in the context of the conflict check.
<oprypin>
well, these two things could be indistinguishable both technically and semantically
<FromGitter>
<bew> Seems it keeps the type ://play.crystal-lang.org/#/r/2xng
<FromGitter>
<bew> Then why B.x prints nil in your last example?
<FromGitter>
<bew> (before last)
<oprypin>
> i hypothesize that assigning the class variable anywhere in the subclass makes the compiler forget all information about it from the parent class
<FromGitter>
<bew> Is there a way to get/know/print all the possible exceptions that a method can raise? (Recursively looking at the methods in that method)
<oprypin>
well that file contains everything you want to know but probably not in a helpful way
Kug3lis_off is now known as gcds
<FromGitter>
<bew> I've read that file already,but still, how can a `raise` be rescued: when we call `raise` it seems that it will inevitably call LibUnwind which (if I understand correctly) is responsible for printing a stacktrace
<oprypin>
the backtrace is not a mandatory part
<oprypin>
the important part is popping things of the stack until there is a guard that catches an exception
<oprypin>
and then i guess it could just do `if that_thing.is_a? SpecifiedExceptionType; handler; else; keep on keeping on`
gcds is now known as Kug3lis_off
<FromGitter>
<bew> Hmm interesting,do you know where/how is this "guard" defined?
<oprypin>
wish i did. this is all speculation anyway
<oprypin>
what i was leading to is, because is_a? can work without any compile-time information, it's entirely possible that exception types are not tracked by the compiler
<jsn->
bew, i don't know how crystal and/or libunwind does it, but guards per se are not hard; see setjmp/longjmp documentation for C, for example
Kug3lis_off is now known as gcds
<FromGitter>
<bew> Those *jmp C functions are to jump to a specific context iirc
<jsn->
yes, setjmp is "set guard", and longjmp is "unwind the stack till we return to the guard"
<jsn->
[well, not exactly, but not unlike that]
<oprypin>
convenient to have this explanation :)
<jsn->
exceptions are not overly interesting though, e.g. call-with-current-continuation is a bit less boring :)
snsei has quit [Remote host closed the connection]
rohitpaulk has quit [Ping timeout: 260 seconds]
alex`` has quit [Read error: Connection reset by peer]
rohitpaulk has joined #crystal-lang
RickHull has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 248 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 248 seconds]
rohitpaulk has joined #crystal-lang
snsei has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 255 seconds]
snsei has quit [Remote host closed the connection]
<FromGitter>
<pnloyd> Since instance variables can always be accessed by object users, would it be reasonable to say encapsulation is provided by convention of only using getting and settings just not modifying instance variables directly?
<FromGitter>
<pnloyd> getters and setters*
<oprypin>
pnloyd, yes. that, and not documenting this ability xD
jackivan88 has quit [Remote host closed the connection]
<jsn->
the ugliness of a.@b notation also helps
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
noblehelm has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
<noblehelm>
how do i get the length of an array?
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
<RX14>
also you cant modify
<RX14>
foo.@bar = bar is not a thing
<FromGitter>
<bew> noblehelm: you can use `Array#size`, as in: `my_array.size`
<oprypin>
RX14, isnt it?
snsei has quit [Remote host closed the connection]
<FromGitter>
<sdogruyol> lol I really laughed hard :P
<FromGitter>
<sdogruyol> who knows what's gonna happen
<FromGitter>
<sdogruyol> it's fun for sure
<Papierkorb>
It's infuriating and frustrating to have the creator of a language rise from the dead from nowhere, then turns out to have drank the functional programming kool-aid, and now produces such harmful noise.
<FromGitter>
<sdogruyol> yeah, I also don't get whats the point about algebraic datatypes
<FromGitter>
<Rinkana> In other news, and idea for when the new version will be released? It's been quite some time and for such a 'small' language some news is better than none
<Papierkorb>
Good question, there has been a ton of changes and improvements since the last release
<oprypin>
Rinkana, last i heard the status was "just merge these last changes" and all of them were merged a few weeks ago
<oprypin>
no participation from Manas in those weeks
<FromGitter>
<Rinkana> Yeah that's what i tought too
<FromGitter>
<sdogruyol> we have the biggest diff ever..
<FromGitter>
<Rinkana> I hope that it'll be released next week
<RX14>
they said they were going to release it this week
<FromGitter>
<Rinkana> I'm not allowed to do sunday releases, and i don't think Manas will do that either :P
<FromGitter>
<sdogruyol> noone should be allowed to do that...
<FromGitter>
<Rinkana> So hopefully somewhere next wee
<FromGitter>
<Rinkana> -k
DTZUZO has joined #crystal-lang
jackivan88 has joined #crystal-lang
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
<FromGitter>
<krypton97> Have you devs ever thought about releasing an unix v1.0 crystal, before adding windows support?
<FromGitter>
<krypton97> I don't think that windows is more used in production than unix since the license is not cheap at all
<RX14>
no because windows isnt even the holdup
<RX14>
windows and parallelism are the holdups to becoming popular
<RX14>
and then we can start even thinking about calling it 1.0
<FromGitter>
<krypton97> Does it require some assembly knowledges for the threading part?
<FromGitter>
<krypton97> Parallelism*
<RX14>
to implement?
<RX14>
probably not
alex`` has quit [Quit: WeeChat 1.9.1]
<FromGitter>
<krypton97> Yeah, I was referring to the implementation. Just saw an twitter post where they got something working on, gj
snsei has quit [Remote host closed the connection]
<FromGitter>
<crisward> Thing is, the features that make v1 of any project are arbitrary. It's api stability that matters. v1 of crystal could be the next release, as long as you're prepared to call the next api break v2. If windows support and parallelism are going to have major breaking api changes the perhaps they could just be v2, or we wait until they're finished before v1. Not sure what's best for the language?
<oprypin>
short term v1 and later v2 is good. long term v1 later is good.
<RX14>
people kinda flame swift for doing that though oprypin
<oprypin>
doing what
<RX14>
many breaking changes
<RX14>
they release a major like every year
<oprypin>
im saying thats bad
<RX14>
"short term v1 and later v2 is good"
<oprypin>
good in short term: v1 and later v2. good in long term: v1 later.
<RX14>
ohh
<RX14>
i misparsed your message
<oprypin>
yeah it was a trainwreck of a message
<RX14>
lol
<FromGitter>
<crisward> Could the groundwork for these additions, so the api can remain stable? ie, prevent people doing things now, that wouldn't be possible later? Or is all that stuff just unknowns?
<oprypin>
groundwork for parallelism is there in terms of API but not awareness
<RX14>
also pretty much everything is not thread safe
RickHull has quit [Ping timeout: 260 seconds]
<RX14>
but is treated as if it is
<oprypin>
groundwork for Windows is impossible to guess until someone looks into the implementation of (all aspects of) Windows support
<FromGitter>
<crisward> Is the aim for windows a full production environment, or just for dev env ?
<RX14>
mostly just for dev env
<RX14>
like
<oprypin>
i dont get it
<RX14>
we'll make it as good as we can
<RX14>
as soon as we can
<RX14>
with the resources we have
<RX14>
what's the question here
<FromGitter>
<crisward> Just that devs seem to be managing with that windows linux thing...
<RX14>
ok
<FromGitter>
<crisward> not a good example, but swift is linux/mac
<RX14>
thats only for w10
<RX14>
also it's not native
<RX14>
it's ok for development i guess but not for windows development
<RX14>
like
<RX14>
i guess you're thinking about this in terms of a web developer
<RX14>
no we want to be able to deploy crystal GUI apps to windows users
<RX14>
so as i said
<RX14>
we want to make it as good as we can
<FromGitter>
<crisward> ok
snsei has joined #crystal-lang
_whitelogger has joined #crystal-lang
<FromGitter>
<crisward> Anyone know if the results of the crystal survey got published?
<RX14>
isn't that @sdogruyol's survey?
<FromGitter>
<crisward> I think so. Just curious as to what came of it.
<FromGitter>
<drosehn> A quick comment on a tangent from hours (days?) ago: <RickHull> fromIRC mentioned something about renaming things in C++. If you have about five minutes, you might want to watch the video about "Things that Matter" by Scott Meyers at: https://youtu.be/RT46MpK39rQ?t=25m11s (jumping 25 minutes into the video). He'll give a short example on why it's so hard to write good IDE's for C++ .
<FromGitter>
<drosehn> There's a lot of other interesting points in that video, but it the full presentation is a little over an hour long. The presentation isn't specific to C++, although that 5-minutes of it focuses on C++. *Disclaimer: I pretty much hate C++*
<FromGitter>
<drosehn> And while I'm revisiting the past, I thought the video that @sdogruyol posted (with Simon Sinek talking) was pretty good. And I'm usually not happy with videos about one "generation" vs other "generations".
<FromGitter>
<pnloyd> I don't think the points about cell phones being addicted is exclusive to younger generations. I see it effecting everyone without pregodice
<FromGitter>
<pnloyd> Prejudice*
<oprypin>
wait what
<RX14>
wat/10
balduin has quit [Remote host closed the connection]
<FromGitter>
<pnloyd> Was a video talking about how millennials are born into a world teaching them they always win, everything comes instantly.
<FromGitter>
<pnloyd> Then they enter the corporate world and break down learning it's not true
<RX14>
@drosehn thats a really interesting talk thanks