00:12
<
FromGitter >
<raydf> @andreaTP , if you're in desktop, or maybe in the mobile app look at the activity tab of this gitter channel, you'll see the main contributors working live fixing issues and adding new features almost daily. Also there's a great community creating shards for different needs.
00:15
soveran has joined #crystal-lang
00:15
soveran has quit [Changing host]
00:15
soveran has joined #crystal-lang
00:21
soveran has quit [Ping timeout: 260 seconds]
00:30
<
splitty_ >
Does `return` return from the innermost or outermost loop?
00:30
akwiatkowski has quit [Ping timeout: 264 seconds]
00:37
matp has quit [Quit: ZZzzzZz...]
00:40
snapcase has quit [Ping timeout: 240 seconds]
00:46
_whitelogger_ has joined #crystal-lang
00:57
twisterghost has quit [*.net *.split]
01:06
<
FromGitter >
<cjgajard> splitty_, `return` ends a method execution instanstaneosly. `break` stops the innermost loop. example:
https://carc.in/#/r/1hi9
01:07
twisterghost has joined #crystal-lang
01:07
<
splitty_ >
Thanks cjgajard
01:07
<
splitty_ >
Does anyone know how to pop a value from the stack and store it in a variable using inline asm? LD
01:10
snapcase has joined #crystal-lang
01:33
<
splitty_ >
Is it possible to use generics with a single method instead with the whole struct/class?
01:41
Marco____ has joined #crystal-lang
01:43
<
Marco____ >
hey, I'm trying to use crystal on Fedora 25, but I think the problem is that fedora only bundles boehm gc 7.4
01:44
<
Marco____ >
by any chance, has anyone packaged crystal for fedora/in general with the right version of boehm gc statically linked or bundled together?
02:07
Marco____ has quit [Quit: Page closed]
02:19
soveran has joined #crystal-lang
02:24
soveran has quit [Ping timeout: 268 seconds]
02:26
pawnbox has joined #crystal-lang
02:45
pawnbox has quit [Remote host closed the connection]
03:10
Marco_ has joined #crystal-lang
03:25
mgarciaisaia has joined #crystal-lang
03:39
mgarciaisaia has quit [Ping timeout: 246 seconds]
03:45
mgarciaisaia has joined #crystal-lang
03:45
mgarciaisaia has quit [Client Quit]
03:48
pawnbox has joined #crystal-lang
03:58
<
FromGitter >
<cjgajard> thanks!
03:59
Marco_ has quit [Quit: Page closed]
04:20
soveran has joined #crystal-lang
04:25
soveran has quit [Ping timeout: 256 seconds]
05:02
matp has joined #crystal-lang
05:21
soveran has joined #crystal-lang
05:26
soveran has quit [Ping timeout: 256 seconds]
05:47
lacour has quit [Quit: Leaving]
05:56
gewo has quit [Ping timeout: 258 seconds]
06:00
txdv has joined #crystal-lang
07:23
soveran has joined #crystal-lang
07:24
vivus-ignis has joined #crystal-lang
07:24
pawnbox has quit [Remote host closed the connection]
07:25
pawnbox has joined #crystal-lang
07:28
soveran has quit [Ping timeout: 256 seconds]
07:30
pawnbox has quit [Remote host closed the connection]
07:33
pawnbox has joined #crystal-lang
07:36
<
FromGitter >
<andreaTP> Just to clarify a typo yesterday, Actors memory footprint is 300 bytes not KB
07:36
<
FromGitter >
<sdogruyol> that's cool :D
07:44
<
FromGitter >
<sdogruyol> @txdv Erlang Actor
07:51
soveran has joined #crystal-lang
07:53
<
FromGitter >
<andreaTP> Even Akka ones is similar
07:59
pawnbox has quit [Ping timeout: 252 seconds]
08:00
pawnbox has joined #crystal-lang
08:16
akwiatkowski has joined #crystal-lang
08:20
pawnbox has quit [Remote host closed the connection]
08:31
mark_66 has joined #crystal-lang
08:43
DTZUZU2 has quit [Ping timeout: 250 seconds]
08:44
dtzu has quit [Ping timeout: 250 seconds]
08:48
vivus-ignis has quit [Ping timeout: 258 seconds]
09:36
pawnbox has joined #crystal-lang
09:45
vivus-ignis has joined #crystal-lang
09:54
vivus-ignis has quit [Ping timeout: 248 seconds]
10:01
_whitelogger has joined #crystal-lang
10:01
Raimondii has joined #crystal-lang
10:02
pawnbox has quit [Remote host closed the connection]
10:04
Raimondi has quit [Ping timeout: 244 seconds]
10:04
Raimondii is now known as Raimondi
10:08
DTZUZU2 has joined #crystal-lang
10:09
dtzu has joined #crystal-lang
10:10
aurelien has joined #crystal-lang
10:10
<
aurelien >
Hello Crystal!
10:10
pawnbox has joined #crystal-lang
10:11
<
FromGitter >
<sdogruyol> @aurelien hello
10:12
<
aurelien >
what is the best way to comment block in .cr?
10:14
* aurelien
hope secretly that have been improved from ruby =begin =end to something more design 8-D
10:23
pawnbox has quit [Remote host closed the connection]
10:24
<
FromGitter >
<sdogruyol> i use # for all
10:30
<
RX14 >
I think it's much nicer to select blocks and toggle commenting in your editor, instead of having a block comment syntax
10:35
<
aurelien >
RX14: that is right ... emacs do that. But, maybe since there is a go side in crystal maybe the
*//* and // was usuable too
10:45
<
RX14 >
I don't think there's any of go
10:45
<
RX14 >
s syntax in crystal
11:10
<
FromGitter >
<barisbalic> Is there any way of contacting the owner of crystalshards.xyz? There's no contact details on the page, and no obvious repo in github
11:14
gewo has joined #crystal-lang
11:24
dtzu has quit [Ping timeout: 264 seconds]
11:33
<
FromGitter >
<barisbalic> @RX14 wow, I must have mispelled crystalshards when I searched. That was dumb, sorry.
11:33
<
RX14 >
no I knew who's github account it was on
11:33
<
RX14 >
i had trouble finding the repo originally too
11:34
<
RX14 >
I had to ask @sdogruyol
11:36
<
FromGitter >
<barisbalic> @RX14 ah okay, good I feel a little less dumb
11:55
pawnbox has joined #crystal-lang
12:00
Philpax has joined #crystal-lang
12:02
pawnbox has quit [Remote host closed the connection]
12:03
pawnbox has joined #crystal-lang
12:07
pawnbox has quit [Remote host closed the connection]
12:08
pawnbox has joined #crystal-lang
12:14
pawnbox has quit [Remote host closed the connection]
12:17
pawnbox has joined #crystal-lang
12:29
vivus-ignis has joined #crystal-lang
12:34
<
aurelien >
is it possible to write chef recipe in crystal?
12:34
<
crystal-gh >
crystal/master 95f0732 Ary Borenszweig: String: make `String.new(capacity)` safe by checking returned bytesize
12:34
<
crystal-gh >
crystal/master 76ee0cb Ary Borenszweig: String: let `String.new(capacity)` realloc buffer if bytesize is less than requested capacity
12:34
<
crystal-gh >
crystal/master 039f77b Ary Borenszweig: Char#_tos: remove extra 0 byte written
12:37
<
aurelien >
which part of go is in crystal?
12:38
<
Papierkorb >
The fiber/channel stuff maybe?
12:39
<
Papierkorb >
Though they probably got that from Erlang. oh well.
12:39
<
RX14 >
i don't think fiber/channel is from erlang
12:39
<
RX14 >
i'm pretty sure it's from go
12:39
<
Papierkorb >
don't they have something like that?
12:39
<
FromGitter >
<barisbalic> It is from go
12:40
<
RX14 >
erlang has actors
12:40
<
FromGitter >
<barisbalic> @Papierkorb erlang has actors
12:40
<
RX14 >
they're different iirc
12:40
<
RX14 >
well, based on what @andreaTP said about them
12:40
<
FromGitter >
<barisbalic> Yes, there's no channels for edample
12:40
<
FromGitter >
<barisbalic> Processes can send messages directly to each other
12:40
<
Papierkorb >
ah okay
12:42
<
aurelien >
ok, thanks
12:43
<
RX14 >
I think crystal is more opinionated than ruby too, I guess you could say thats from go
12:43
<
RX14 >
but the most obvious thing is the concurrency model
12:44
<
Papierkorb >
more opinionated in which way RX14?
12:44
<
aurelien >
is there a documentation page about the crystal model?
12:44
<
RX14 >
crystal concurrency model?
12:45
<
aurelien >
no ... sorry ... just what is crystal, why and which side of each language it use ...
12:45
Philpax has quit [Ping timeout: 248 seconds]
12:46
<
FromGitter >
<Gebriel> hey there
12:46
<
FromGitter >
<barisbalic> @Papierkorb it has code formatting tools for one thing
12:46
<
FromGitter >
<Gebriel> is there a guide or book to study crystal
12:46
<
RX14 >
aurelien, well thats pretty complex
12:47
<
FromGitter >
<Gebriel> without ruby knowledge
12:47
<
aurelien >
RX14: certainly, but that would be pretty cool to light the dark corner of knowledge
12:48
<
RX14 >
aurelien, well it's basically ruby-inspired syntax with static typing, heavily ruby-inspired stdlib, and go concurrency
12:49
<
RX14 >
the type inference system is unique to crystal I'm pretty sure
12:50
<
FromGitter >
<barisbalic> I'd say the stdlib is actually nicer
12:50
<
RX14 >
yeah it's ruby inspired
12:50
<
FromGitter >
<barisbalic> I guess it has the benefit of coming after ruby, but it's well thought out, and things have saner interfaces (http/client for example)
12:50
<
RX14 >
but cleaned up
12:50
<
RX14 >
both in the stdlib and syntax
12:51
<
RX14 >
for example you need () around method arguments which isn't true for ruby
12:51
<
RX14 >
I mean when defining methods
12:51
<
RX14 >
when calling methods you don't need ()
12:51
<
RX14 >
aurelien, type inferrence hasn't been theoretical for about 20 years
12:56
pawnbox has quit [Ping timeout: 250 seconds]
12:56
<
RX14 >
there's only one place where you need to specify types, and that's for instance and class variables
12:57
<
RX14 >
but a lot of the time they can be inferred too
12:57
<
FromGitter >
<barisbalic> Dem overloads
13:04
mgarciaisaia has joined #crystal-lang
13:09
<
RX14 >
i could argue that you don't need overloads
13:09
<
RX14 >
you could just change method names ;)
13:10
<
aurelien >
is there a way to use crystal in chef recipes?
13:10
<
RX14 >
well actually i've never used chef
13:10
<
RX14 >
so i have no idea
13:10
<
aurelien >
what do you use?
13:11
<
aurelien >
I mean rather than chef? ansible? puppet? home backed script?
13:11
<
RX14 >
I own a grand total of 1 server
13:11
<
RX14 >
which I use docker on
13:11
<
RX14 >
so i guess dockerfiles + docker-compose would be the closest replacement
13:12
scottj has joined #crystal-lang
13:12
<
RX14 >
or do you mean you want to use chef to deploy crystal?
13:13
<
RX14 >
i'm very sure thats possible
13:13
<
aurelien >
certainly possible
13:13
<
aurelien >
no I need to use chef at works
13:14
<
aurelien >
and i do not wish to use ruby
13:15
<
aurelien >
reading about crystal, i was thinking that it would be close enough to ruby to do the job and seems so powerful that it would be cool to learn
13:17
<
Papierkorb >
What's wrong with ruby?
13:17
<
txdv >
hard to use if you are dealing with bits and bytes
13:18
<
txdv >
has no static typing
13:18
<
aurelien >
maybe not close enough to system when you come from bash and C
13:18
<
Papierkorb >
It's not meant to be used for things that need speed, ruby is fast enough for many things, and way too slow for many others
13:19
<
Papierkorb >
But for something like chef, where ruby most of the time waits for a system() command to finish, what's wrong with ruby?
13:19
<
txdv >
i love ruby when speed is not important
13:19
<
RX14 >
if anything you might want to write the odd script in crystal
13:19
<
RX14 >
and call it from chef
13:20
<
RX14 >
but not replace the whole DSL
13:23
<
aurelien >
crystal works fine on Parabola!
13:23
<
aurelien >
and the command is close to go :-)
13:23
<
aurelien >
which ruby have not
13:27
<
aurelien >
Parabola GNU / Linux-libre ... FAIF distro ... the free side of Archlinux
13:28
<
FromGitter >
<barisbalic> @RX14 im not saying overloads are needed, but they are nice
13:28
<
RX14 >
yep they sure are
13:28
<
Papierkorb >
One of the things I miss in ruby is method overloading...
13:28
<
Papierkorb >
(yadda yadda dynamic typing)
13:29
nek_ has joined #crystal-lang
13:35
<
nek_ >
Hello all. I have a question about the language design of Crystal. Is it OK to ask here?
13:37
<
FromGitter >
<asterite> Hi nek_. Sure! :-)
13:38
<
nek_ >
My question is: what the part of Crystal is from Go?
13:38
<
nek_ >
I suppose it's channels, but I can't find the document about it.
13:39
<
FromGitter >
<asterite> Yes, CSP, the concurrency model
13:39
* aurelien
... feel not alone -_-
13:39
<
FromGitter >
<asterite> I don't know if there's a document that says "Go's concurrency model" because it's CSP, which I'm not sure only Go uses
13:40
<
aurelien >
nek_ on my side I have find the command from the terminal that run as go ... for the moment
13:40
pawnbox has joined #crystal-lang
13:42
<
FromGitter >
<andreaTP> @asterite even Clojure use them by default
13:43
go|dfish has quit [Quit: SIGQUIT]
13:47
go|dfish has joined #crystal-lang
13:50
<
nek_ >
Thank you for the answer!!!
13:55
nek_ has quit [Quit: Page closed]
14:03
oddmunds has quit [Quit: WeeChat 1.4]
14:08
bmcginty has quit [Ping timeout: 250 seconds]
14:09
pawnbox has quit [Remote host closed the connection]
14:15
bmcginty has joined #crystal-lang
14:23
gcds has joined #crystal-lang
14:23
<
gcds >
Hello, how I can call parent method of class which I extend?
14:25
<
RX14 >
calling super should work
14:26
soveran has quit [Remote host closed the connection]
14:31
<
splitty_ >
Hey, where is malloc implemented?
14:32
<
RX14 >
crystal by default uses libgc's malloc
14:32
<
splitty_ >
I'm writing a kernel in Crystal, so I can't call Pointer(T).malloc
14:32
<
splitty_ >
I have a custom malloc function which uses my heap allocator, but I don't know where to put it so the compiler detects it
14:32
<
RX14 >
for calling .new?
14:33
<
splitty_ >
RX14, I'm getting
14:33
<
splitty_ >
main_module:(.text+0xa3d): undefined reference to `malloc'
14:33
<
splitty_ >
main_module:(.text+0xa6c): undefined reference to `memset'
14:33
<
splitty_ >
My code is ptr = Pointer(UInt16).malloc 16_u64
14:33
<
RX14 >
you need to define a GC
14:33
<
splitty_ >
Okay, how would I do that so the compiler recognizes it?
14:34
<
splitty_ >
I'm not familiar with the internals of the Crystal compiler/runtime
14:35
<
RX14 >
you should `require "gc"` then `require "./your_gc"`
14:35
<
RX14 >
which is adapted from gc/null whcih i linked
14:35
<
splitty_ >
Thank you, that seems to be exactly what I want :)
14:35
<
RX14 >
you can probably put the `require "gc"` inside your gc definition
14:36
<
RX14 >
and again, i've never done it but it probably works
14:36
pawnbox has joined #crystal-lang
14:36
<
splitty_ >
We'll see in a moment :P
14:36
<
gcds >
is it possible to override private method from parent class? :D
14:39
pawnbox has quit [Remote host closed the connection]
14:40
<
splitty_ >
RX14, how would I cast a Pointer(T) to a Void* ?
14:41
<
RX14 >
pointer.as(Void*)
14:41
<
RX14 >
or .as(Pointer(Void))
14:41
<
RX14 >
it's just the former is much nicer to write
14:41
<
RX14 >
the * syntax is simply an alias, it means the same thing
14:42
<
splitty_ >
RX14, can't cast (Pointer(UInt8) | Nil) to Pointer(UInt8)
14:42
<
RX14 >
well it seems your pointer isn't always a pointer
14:43
<
splitty_ >
Yep the Heap allocation can fail
14:43
<
RX14 >
then you need to handle that case
14:43
<
splitty_ >
Does the static analysis make this possible as soon as I return early in the nil case?
14:44
<
RX14 >
if you use `return unless foo` foo won't be nil after that
14:44
<
RX14 >
because `return` has type NoReturn
14:46
<
splitty_ >
Doesn't seem sufficient though
14:47
<
RX14 >
i would do your equivalent of a kernel panic instead of returning
14:47
<
splitty_ >
btw, thanks for the 'return unless foo'. I was always using 'return if foo.is_a? Nil'
14:47
<
splitty_ >
RX14, yeah that makes sense
14:47
dtzu has joined #crystal-lang
14:47
<
RX14 >
you should be able to mark a method as noreturn manually
14:48
<
RX14 >
then just print + stop the processor i guess?
14:49
<
RX14 >
hopefully later on you can enter a stage where you can unwind the stack
14:49
<
RX14 >
then raise becomes possible
14:51
<
splitty_ >
RX14, the Crystal compiler always surprises me.. in a negative way
14:51
<
splitty_ >
Error undefined constant ::TypeCastError
14:51
<
splitty_ >
That's incredibly helpful
14:52
<
splitty_ >
Considering I don't have a file or a line number.. :D
14:52
<
RX14 >
it isn't really built for use without the stdlib
14:52
ponga has joined #crystal-lang
14:52
<
RX14 >
you'll need to define TypeCastError I guess
14:53
<
splitty_ >
I did type casts before and didn't have any issues with it
14:53
<
splitty_ >
Maybe you see something obvious there ^&
14:54
<
RX14 >
it's the .as call which needs TypeCastError
14:54
<
RX14 >
try uting .as?
14:54
<
RX14 >
which will return nil on a type cast error
14:54
<
RX14 >
instead of raising
14:54
<
splitty_ >
That can't possibly work though, because then I'd have the problem I had before again, wouldn't I?
14:55
<
RX14 >
because then you have Void* | Nil
14:55
<
RX14 >
when you can panic unless block
14:55
<
RX14 >
it's ugly I know
14:56
<
RX14 >
but if you get stack unwinding working you can implement your own Exception class
14:56
<
RX14 >
then all this mess goes away
14:56
<
RX14 >
here's a point
14:56
<
RX14 >
implement exception now
14:56
<
RX14 >
don't do any unwinding
14:56
<
RX14 >
and just panic
14:56
<
RX14 >
class Exception
14:56
<
RX14 >
def self.new(message, cause)
14:57
<
RX14 >
then you can use `raise` to mean kernel panic here with this message
14:58
<
splitty_ >
So, if my understand of that is right, I'd do Heap.alloc(size).as?(Void*)
14:58
<
splitty_ >
And then raise if block.is_a? Nil
14:58
p0p0pr37 has quit [Remote host closed the connection]
14:58
<
RX14 >
actually if you implemented TypeCastError you could just do
14:59
<
RX14 >
block = Heap.kalloc(size)
14:59
<
RX14 >
raise unless block
14:59
<
RX14 >
block.as(Void*)
14:59
<
RX14 >
.as will never really raise as the available types are always compatible
14:59
<
RX14 >
you just get a panic if your allocation fails
15:00
<
splitty_ >
Would class TypeCastError < Exception end suffice?
15:00
<
RX14 >
actually not
15:00
<
RX14 >
you need to add the new method
15:00
<
RX14 >
the definition in the stdlib should suffice
15:00
<
splitty_ >
I guess I can call super.new then?
15:01
<
RX14 >
it's just because subclasses don't inherit constructors iirc
15:01
<
BlaXpirit >
splitty_, no, super is not the superclass, it's the ... supermethod
15:02
<
RX14 >
yeah where the super method here is Exception's initialize
15:02
<
RX14 >
which should kernel panic
15:02
<
splitty_ >
Okay so I'd just call super?
15:02
<
RX14 >
actually it might be better to define self.new() on exception
15:02
<
RX14 >
def self.new(*args); kernel panic; end
15:03
<
splitty_ >
oops I forgot to inherit Exception
15:03
<
RX14 >
that might work
15:03
<
splitty_ >
Do I have to import something to make raise work?
15:03
<
RX14 >
that should work to my eye
15:03
<
RX14 >
do you get an error using raise?
15:03
<
splitty_ >
I'm getting undefined local variable or method 'raise'
15:04
<
splitty_ >
The joy of doing OS dev haha
15:05
<
RX14 >
this looks like the files
15:05
<
RX14 >
just define all the applicable raise methods to kernel panic
15:06
<
RX14 >
and stub out TypeCastError to be a struct
15:06
<
RX14 >
which takes the initialize arguments and does nothing
15:11
<
splitty_ >
I implemented __crystal_personality, __crystal_raise, raise, raise(Exception), raise(String) and __crystal_raise_string
15:12
<
splitty_ >
Now it finds raise, but I'm having another problem now
15:12
<
RX14 >
do you need __crystal_personality?
15:12
<
RX14 >
i'm not all to sure how the unwinding works
15:12
<
splitty_ >
Not sure. Can't hurt. In Rust I always defined the personality function when writing OSes
15:13
<
splitty_ >
Oh please no :/
15:13
<
splitty_ >
undefined constant ::String::Builder
15:13
<
splitty_ >
Now, this is a problem. :D
15:14
<
RX14 >
yes the compiler uses the stdlib quite a bit
15:14
<
splitty_ >
Let's see..
15:14
<
splitty_ >
I don't see Strings used here
15:14
<
splitty_ >
Why would it want me to implement ::String::Builder
15:14
<
RX14 >
however, now you've defined GC.malloc you might in fact be able to import the whole of string
15:15
<
RX14 >
probably not
15:15
<
splitty_ >
while requiring "c/stdlib": can't find file 'c/stdlib' relative to '/opt/crystal/src'
15:15
<
RX14 >
yeah that wont work
15:15
<
RX14 >
.as probably uses ::String::Builder to build it's error message
15:16
<
splitty_ >
I'm using as quite a lot in my code and it never does this
15:16
<
splitty_ >
Only here, for some reason
15:17
<
splitty_ >
Honestly though, I might be able to implement String::Builder
15:18
<
Papierkorb >
The third OS in Crystal?
15:19
<
splitty_ >
The was a second one?
15:19
<
splitty_ >
I only know about one other OS
15:19
<
RX14 >
maybe it would just be better to use .as? after all
15:19
<
splitty_ >
Maybe ^^
15:19
<
Papierkorb >
to the best of my knowledge, mine was the first splitty_
15:19
<
Papierkorb >
Another one in the last weeks by someone
15:20
<
splitty_ >
Papierkorb, is it on GitHub?
15:20
<
splitty_ >
Ah that's why I didn't know about it :P
15:21
<
Papierkorb >
It "lives" only in my private git
15:21
<
splitty_ >
Chronium started it but I pretty much implemented everything, because Chronium is lazy :D
15:22
<
Papierkorb >
Mine was in long mode, I borrowed some .asm files from the rust tutorial os
15:22
<
splitty_ >
Ha, I borrowed my Heap from my Rust OS :D
15:23
<
Papierkorb >
That I wrote myself, buddy allocation algorithm
15:23
<
splitty_ >
Interesting
15:23
<
Papierkorb >
was surprisingly fast
15:24
<
splitty_ >
I don't get where the dependency on ::String::Builder comes from..
15:24
<
splitty_ >
RX14, that shouldn't happen with as?, should it?
15:24
<
RX14 >
.as can create a TypeCastError
15:25
<
splitty_ >
I'm now using `.as?` though
15:25
<
RX14 >
which uses a StringInterpolation node to create the TypeCastError message
15:25
<
RX14 >
and the codegen for the StringInterpolation uses String::Builder
15:25
<
RX14 >
and i'm not sure
15:25
<
RX14 >
but i don't think so
15:26
<
splitty_ >
It also still wants me to define TypeCastError
15:26
<
Papierkorb >
splitty_: I did not implement String::Builder, I only used a skeleton String class by taking the original one and throwing everything out that uses IO or Builder
15:26
<
RX14 >
i don't think so
15:26
soveran has joined #crystal-lang
15:27
<
RX14 >
Papierkorb, if you use .as and the compiler decides the type cast could fail, then you need to define String::Builder
15:27
<
Papierkorb >
Sure it was less convenient, but the TTY.print method simply accepted multiple arguments instead, which was good enough for me
15:27
<
RX14 >
this is the call which requires String::Builder
15:27
<
gcds >
Guys I have question regarding extending class methods... I have extend class replaced method but in parent class method which should call my replaced method is not called...
15:28
<
splitty_ >
RX14, I'm just gonna drop the as stuff and return a null pointer if the heap allocation fails
15:28
<
Papierkorb >
RX14: I didn't need it, either that was different in september (git logs ftw), or I worked around it
15:29
<
Papierkorb >
But I only added the "real" classes later on and carefully. Worked except for complex classes like Array or Hash :|
15:30
<
RX14 >
Papierkorb, well you must not have hit n .as which codegeneed that
15:30
<
FromGitter >
<raydf> Hello everyone
15:30
<
RX14 >
i think that might be new
15:30
<
FromGitter >
<raydf> is there any way to convert a parameters array to an splat of args?
15:30
<
RX14 >
because maybe the line number at which the type cast failed was only added recently
15:30
<
RX14 >
that must be it
15:31
<
Papierkorb >
RX14: searching for it shows that I only used .as with pointer types
15:31
<
RX14 >
this is when it was changes
15:31
soveran has quit [Ping timeout: 256 seconds]
15:32
<
Papierkorb >
I began much later: `Mon Sep 19 23:06:59 2016 +0200`
15:32
<
RX14 >
you never hit that case in the compiler I guess
15:32
<
Papierkorb >
yip :)
15:33
<
Papierkorb >
Anyway, I stopped dev'ing that when the joys of Crystal didn't outweight its issues (for that use-case) anymore
15:35
<
FromGitter >
<raydf> found it
15:35
<
FromGitter >
<raydf> Tuples.from(Array)
15:35
<
Papierkorb >
But I'm still interested in doing other low-level things with it. The biggest roadblocks are 1) IO 2) no GC. If you have both you can again do whatever you want without too much hassle
15:36
<
Papierkorb >
Which are given (mostly) for services in microkernel systems
15:37
<
splitty_ >
Error in src/heap.cr:51: Bug: no target defs
15:37
<
splitty_ >
What's that o_O
15:38
<
splitty_ >
brb, eating
15:38
<
RX14 >
sounds like a compiler bug to me
15:38
<
splitty_ >
Well I think I know what's happening
15:39
<
RX14 >
a call with no targets
15:39
<
RX14 >
if you can trace the code from here
15:43
matp_ has joined #crystal-lang
15:46
<
splitty_ >
That's so strange..
15:46
matp has quit [Ping timeout: 260 seconds]
15:46
<
RX14 >
where's heap.cr:51
15:47
<
splitty_ >
@@instance.as(Heap).kalloc size
15:47
<
splitty_ >
@@instance is a Heap?
15:47
<
RX14 >
which makes the raise code be generated
15:47
<
RX14 >
you need a .build method that yields
15:48
<
RX14 >
yield/no yield differentiates methods
15:48
<
RX14 >
it probably codegenned a yielding one
15:48
<
RX14 >
one with a block
15:48
<
splitty_ >
Nothing changed when I made self.build yield a String.new
15:49
<
RX14 >
you need to yield a String::Builder
15:49
<
splitty_ >
I thought I had to yield a String
15:49
<
splitty_ >
Because the signature was def self.build(capacity : Int = 64) : String
15:50
<
RX14 >
no it creates a new builder, yields the builder, the creates a string from the builder
15:50
<
splitty_ >
def self.build(capacity : Int = 64) : String
15:50
<
splitty_ >
String.new
15:50
<
splitty_ >
yield String::Builder.new String.new
15:50
<
splitty_ >
This doesn't work either
15:50
<
RX14 >
well no because that doesn't compile?
15:51
<
splitty_ >
Why wouldn't it compile?
15:51
<
RX14 >
you're calling self.new(String)
15:51
<
RX14 >
which doesn't return a String::Builder
15:52
<
splitty_ >
The error messaged should be a little more clear..
15:52
<
RX14 >
what was the error?
15:52
<
RX14 >
still the Bug: one?
15:52
<
splitty_ >
And I can't make it go away
15:52
<
splitty_ >
If I return a String::Builder.new from String::Builder.new(String) it still doesn't change anything
15:53
<
FromGitter >
<asterite> gcds: can you show some code?
15:53
<
RX14 >
thats interesting
15:54
<
RX14 >
it doesn't use the block version
15:54
<
gcds >
FromGitter: Sorry I still not used to Crystal global instances and stuff it was called somewhere before my replaced method was called...
15:54
<
gcds >
asterite: Sorry I still not used to Crystal global instances and stuff it was called somewhere before my replaced method was called...
15:55
<
RX14 >
splitty_, your code should work...
15:55
<
splitty_ >
Right? :P
15:55
<
splitty_ >
I have no idea what that bug thing is
15:55
<
splitty_ >
Like, that exact line of code worked fine before
15:55
<
splitty_ >
I don't know what changed.
15:56
<
RX14 >
.new, << and to_s should be all you need
15:57
<
splitty_ >
I have all of those implemented
15:58
<
RX14 >
try removing the .new(String)?
15:58
<
splitty_ >
Still Bug: no target defs
15:58
<
RX14 >
and that goes away when you remove the .as?
15:59
<
RX14 >
instance = @@instance
15:59
<
RX14 >
panic unless instance
15:59
<
splitty_ >
hmm let me see
15:59
<
splitty_ >
I'll change the Heap a little so that Heap can't be null
15:59
<
splitty_ >
That's silly anyway
16:01
<
splitty_ >
Ah damn I can't change that
16:02
<
splitty_ >
Awesome! Thank you
16:02
<
splitty_ >
That fixed it
16:02
<
splitty_ >
Now I only need to define memset... somewhere
16:03
<
RX14 >
if you want to get string interpolation working you'll have to debug that again
16:03
<
RX14 >
you'll be able to add some puts debugging to the compiler and work that out I think
16:04
<
RX14 >
which exact call fails
16:04
<
splitty_ >
Yeah that should be no problem
16:04
<
Yxhuvud >
memset? isn't that a llvm builtin?
16:04
<
splitty_ >
RX14, do you happen to know where memset is defined?
16:04
<
splitty_ >
Yxhuvud, yes but I'm writing a kernel
16:04
<
RX14 >
why do you need that?
16:05
<
splitty_ >
RX14, to set my dank memes
16:05
<
Papierkorb >
sdogruyol, to you too if you're still interested in the memory allocator
16:05
<
splitty_ >
I need it because it's needed for malloc
16:05
<
Papierkorb >
It's not
16:05
<
RX14 >
those intrinsics should work
16:06
<
splitty_ >
Nice, thank you
16:06
<
Papierkorb >
splitty_: malloc allocates memory, it does not initialize it
16:07
<
splitty_ >
Papierkorb, I know. malloc complains about needing __crystal_malloc and memset though
16:07
<
Papierkorb >
splitty_: ... you don't have malloc() yet if you didn't define it yourself
16:08
<
splitty_ >
Papierkorb, I defined it myself. I think we're misunderstanding each other here.
16:08
<
splitty_ >
Papierkorb, ptr = Pointer(UInt16).malloc 16_u64
16:08
<
splitty_ >
This is my code.
16:08
<
splitty_ >
Now if I run this
16:08
<
splitty_ >
I'm getting two error messages
16:08
<
splitty_ >
main_module:(.text+0xa3d): undefined reference to `malloc'
16:08
<
splitty_ >
main_module:(.text+0xa6c): undefined reference to `memset'
16:08
<
splitty_ >
Now that I have implemented malloc
16:08
<
Papierkorb >
Well malloc() should be no more than a call to your allocator
16:08
<
splitty_ >
I need to implement memset. I still have a memset function, but it isn't recognized by the compiler
16:08
<
splitty_ >
Papierkorb, theoretically, yes. But practically there's the crazy GC stuff involved
16:09
<
Papierkorb >
splitty_: memset isn't too hard, you can borrow it from my code if you want ^
16:09
mark_66 has quit [Remote host closed the connection]
16:09
<
Papierkorb >
You neither have the GC
16:09
<
splitty_ >
As I said, I already have it, I just need the compiler to recognize it, but thanks anyway :D
16:09
Sharcho has joined #crystal-lang
16:10
<
RX14 >
memset should be defined in the compiler
16:10
<
RX14 >
using llvm.memset.p0i8.i32
16:10
<
RX14 >
which is an intrinsic
16:11
<
splitty_ >
Well in my Rust kernel I had to override the intrinsics too
16:12
<
splitty_ >
RX14, how do global paths work?
16:12
<
splitty_ >
If I define memset I can't call my 'real' memset in ./memory.cr anymore
16:12
<
splitty_ >
In Rust I can do ::memset to get a global path to memset
16:14
<
RX14 >
yeah you can use :: to anchor your path in crystal too
16:14
<
splitty_ >
Well I tried that, I got 'unexpected token: ::'
16:14
<
splitty_ >
fun memset (dest : Void*, val : UInt8, len : UInt32, align : UInt32, is_volatile : Bool)
16:14
<
splitty_ >
::memset dest, val, len
16:14
<
splitty_ >
Probably doing it wrong
16:15
<
splitty_ >
Bear with me, I started writing Crystal code yesterday :P
16:15
<
RX14 >
you'll have to move memset to a module
16:15
<
RX14 >
you can only ancor types
16:15
<
splitty_ >
Ah, I see
16:15
<
RX14 >
if a top-level method goes out of scope there's no way to call it i'm pretty sure
16:15
Sharcho has quit [Quit: Leaving]
16:15
<
RX14 >
so you'll have to move it to a module
16:17
<
splitty_ >
RX14, could you give me an example please?
16:17
<
splitty_ >
I moved the memory functions to a module
16:17
<
splitty_ >
How do call memset inside of the Memory module now?
16:17
<
splitty_ >
Tried ::Memory::memset, Memory::memset and Memory.memset
16:17
<
RX14 >
def self.memset in the module
16:17
<
RX14 >
then Module.memset
16:18
<
splitty_ >
Syntax error in src/lib/intrinsics.cr:5: expecting token '=', not '.'
16:18
<
splitty_ >
Memory.memset dest, val, len
16:19
<
RX14 >
can you show me the whole code
16:20
<
RX14 >
of both the definition and call
16:21
<
RX14 >
try removing the space between the memset and ()
16:21
<
RX14 >
in the instrinsics.cr
16:22
<
splitty_ >
Doesn't change anything
16:22
<
RX14 >
thats super weird
16:22
<
splitty_ >
Well, better than BUG: No target defs
16:24
<
RX14 >
add () around the memeset call on line 5
16:24
<
RX14 >
and screenshot it again
16:24
<
splitty_ >
Still doesn't compile
16:26
<
RX14 >
yeah libs are for binding external functions
16:26
<
RX14 >
if you remove the lib
16:26
<
RX14 >
that will work
16:26
<
splitty_ >
Well all I'm trying to do is mimic
16:26
<
splitty_ >
fun memset = "llvm.memset.p0i8.i32"(dest : Void*, val : UInt8, len : UInt32, align : UInt32, is_volatile : Bool)
16:26
<
splitty_ >
And make it use my own memset function
16:26
<
RX14 >
there are different syntax rules inside lib
16:27
<
splitty_ >
So that the compiler can finally link it and make malloc work
16:27
<
RX14 >
splitty_, the compiler doesn't use that memset definition
16:27
<
RX14 >
thats simply a binding for the standard library
16:27
<
RX14 >
the compiler uses the llvm instrinsic directly
16:27
soveran has joined #crystal-lang
16:28
<
splitty_ >
So where should I define it so that the following compiler error goes away:
16:28
<
splitty_ >
main_module:(.text+0xa6c): undefined reference to `memset'
16:28
<
RX14 >
which seems to just be generating a call to a function called memset
16:28
<
RX14 >
so define a top level function called memset using fun
16:28
<
RX14 >
and the linker will find it
16:28
gcds has quit [Quit: Page closed]
16:28
<
RX14 >
i mean literally remove the lib and place fun memset on the top level
16:29
<
RX14 >
and it'll work i think
16:29
<
splitty_ >
Makes sense. How would I define memset though?
16:29
<
splitty_ >
Currently
16:29
<
splitty_ >
I'm doing it like this: def memset(dst : Pointer(_), c : UInt8, n : USize) : Pointer
16:30
<
splitty_ >
In a fun, the Pointer(_) doesn't work
16:30
<
splitty_ >
I could change it to Void*, but how would I set values then?
16:30
<
splitty_ >
Afaik I can't set anything because my Pointer(T) requires the []= value to be T
16:31
<
splitty_ >
And there's no T such that T is typeof(Void)
16:31
<
RX14 >
def = define mangled function
16:31
<
RX14 >
fun = define unmangled function
16:31
<
RX14 >
the lniker is failing to find "memset"
16:31
<
RX14 >
so you just need to define fun memset
16:32
<
splitty_ >
Without any content? Just fun memset?
16:32
<
RX14 >
and make it call your memset
16:32
<
RX14 >
define your memset inside that fun
16:32
<
splitty_ >
Yeah that's my issue.
16:32
<
splitty_ >
I don't know how I would make memset work inside a fun
16:32
<
splitty_ >
Because of what I described above
16:33
soveran has quit [Ping timeout: 256 seconds]
16:33
<
splitty_ >
Let's say I write it like this: fun memset(dst : Void*, c : UInt8, n : USize) : Void*
16:33
<
splitty_ >
Then I couldn't actually set any values
16:33
<
RX14 >
cast it to a UInt8* i should think
16:34
<
RX14 >
define it as a UInt8*
16:34
<
RX14 >
i think it'll link regardless
16:38
<
splitty_ >
Yay it compiles
16:38
<
splitty_ >
Now I just need to find out why it panics
16:38
<
RX14 >
its progress
16:39
<
RX14 >
define your panic function with
__FILE__ arg
16:39
<
RX14 >
and print it
16:39
<
RX14 >
so you can see where it was called from
16:43
<
splitty_ >
RX14, it's called from lib/panic.cr
16:43
<
splitty_ >
Oh nevermind
16:43
<
splitty_ >
I guess I'll have to pass __FILE__, I just printed it in panic.cr...
16:44
<
RX14 >
oh i didn't explain the
__FILE__ syntax correctly
16:44
<
RX14 >
def foo(file = __FILE__)
16:45
<
RX14 >
where file will become the
__FILE__ of the caller
16:45
<
RX14 >
you can pass it down callchains too
16:48
<
splitty_ >
Are there also macros for line number, etc?
16:49
pawnbox has joined #crystal-lang
16:50
<
RX14 >
uhh i think so
16:50
<
RX14 >
__LINE__ might work
16:50
<
RX14 >
they're used here
16:50
<
RX14 >
for reference
16:51
<
RX14 >
__END_LINE__ is for blocks
16:51
<
FromGitter >
<raydf> @bcardiff , how can i use crystal-db for dynamically generated queries?, in crystal-pg you were able to pass an array of params instead of an splat.
16:51
<
splitty_ >
Nice,
__LINE__ works. Now I just need to implement to_s for Int :D
17:12
vivus-ignis has quit [Quit: vivus-ignis]
17:13
vivus-ignis has joined #crystal-lang
17:13
vivus-ignis has quit [Client Quit]
17:14
vivus-ignis has joined #crystal-lang
17:23
<
splitty_ >
How do I specify the prelude?
17:23
<
splitty_ >
--prelude=path/to/prelude/prelude.cr doesn't work
17:24
olek_poz has joined #crystal-lang
17:24
<
RX14 >
i think it has to be on the require path
17:25
<
RX14 >
if you can require the value for prelude
17:25
<
RX14 >
you'll need to specify an absolute or relative path
17:25
dtzu has quit [Ping timeout: 258 seconds]
17:25
<
splitty_ >
Well I do --prelude=./kernel/src/lib/prelude.cr
17:25
<
Papierkorb >
RX14: --prelude only searches the compilers search path, nothing else
17:26
akwiatkowski has quit [Ping timeout: 264 seconds]
17:26
<
RX14 >
it says just Require.new(prelude)
17:26
<
RX14 >
where prelude is the prelude given on the commandline
17:26
<
Papierkorb >
Never worked for me :D
17:27
<
splitty_ >
Yeah doesn't seem to be working
17:27
<
Papierkorb >
splitty_: Use the empty prelude and require your "real" prelude in your main.cr or however you call it
17:27
<
RX14 >
yeah that seems to be the only option
17:28
<
splitty_ >
That's how I'm doing it at the moment
17:28
<
splitty_ >
Was just wondering whether there's a better way :P
17:28
<
Papierkorb >
And will still work for some time to come too
17:28
<
RX14 >
its weird it doesn't work
17:28
soveran has joined #crystal-lang
17:30
<
Papierkorb >
RX14: Is the search path not initialized when it resolves the prelude path?
17:30
<
RX14 >
well actually
17:30
<
RX14 >
it seems to just add the node
17:30
<
RX14 >
same as any require
17:34
soveran has quit [Ping timeout: 256 seconds]
17:56
pawnbox has quit [Remote host closed the connection]
18:02
vivus-ignis has quit [Quit: vivus-ignis]
18:02
vivus-ignis has joined #crystal-lang
18:10
<
splitty_ >
Is there something like a stringify macro?
18:11
<
splitty_ >
Something that turns an identifier into a string
18:11
<
Papierkorb >
macro stringify(content) {{ content.stringify }} end
18:12
<
splitty_ >
Thank you
18:15
<
BlaXpirit >
splitty_, well actually it's just "asdfg".id.stringify
18:15
<
BlaXpirit >
so just .stringify
18:15
<
splitty_ >
And that works in a kernel, too? Or does it need a proper runtime
18:16
<
BlaXpirit >
splitty_, um macros are entirely compile time, how would that need a runtime
18:16
<
BlaXpirit >
they do need a runtime but at compile time :p crazy stuff
18:16
<
splitty_ >
Yes the macro is compile time. I just wasn't sure whether stringify needs a runtime :P
18:17
<
BlaXpirit >
anything inside {{ }} can't be runtime
18:17
<
RX14 >
no because it is itself a macro
18:17
<
splitty_ >
Ah, that's nice :(
18:17
<
RX14 >
the string value of the constant will be inserted at compile time
18:17
<
RX14 >
you cannot call it on a variable
18:17
<
splitty_ >
The kernel is getting more usable
18:18
<
splitty_ >
I now have a macro-based test framework
18:18
<
Papierkorb >
You can simply use `spec` ...
18:18
<
splitty_ >
That works?
18:19
<
Papierkorb >
Oh you run that in the kernel?
18:19
<
Papierkorb >
I didn't do it, much more time waste on waiting for qemu (and building everything before) than having a thin wrapper to run the kernel code directly
18:20
<
splitty_ >
Well it's important to know that everything still works after tinkering with the kernel
18:21
<
Papierkorb >
I did write tests, I just ran them in userland on linux
18:23
<
splitty_ >
Oh, okay
18:26
vivus-ignis has quit [Quit: vivus-ignis]
18:27
vivus-ignis has joined #crystal-lang
18:31
soveran has joined #crystal-lang
18:36
soveran has quit [Ping timeout: 256 seconds]
18:44
<
Yxhuvud >
splitty: hmm, do you know of 'crystal tool format'?
18:45
<
Yxhuvud >
or do you just dislike the results? :)
18:48
<
splitty_ >
Yxhuvud, I didn't know of crystal tool format
18:49
<
splitty_ >
For Rust I have rustfmt installed which automatically formats my files
18:49
<
splitty_ >
The Crystal integration with VS code doesn't support that yet
18:56
<
RX14 >
if only everyone used the formatter...
18:58
<
BlaXpirit >
if it didn't make my code look worse, sure
19:02
dtzu has joined #crystal-lang
19:10
<
RX14 >
it doesn't...
19:11
<
RX14 >
it's much much better to be consistent than to stick to your own sense of style
19:11
dtzu has quit [Read error: Connection reset by peer]
19:14
DTZUZU2 has quit [Ping timeout: 252 seconds]
19:23
matp_ has quit [Remote host closed the connection]
19:24
matp has joined #crystal-lang
19:28
<
FromGitter >
<andreaTP> @RX14 you are right but it isn't mentioned anywhere
19:28
<
FromGitter >
<andreaTP> So newcomers.like me aren't aware
19:28
<
RX14 >
about what sorry? whats the context here?
19:29
<
FromGitter >
<andreaTP> The formatter
19:29
<
FromGitter >
<andreaTP> I mean
19:29
<
RX14 >
thats a good point
19:30
<
RX14 >
you think it should be mentioned in the docs?
19:30
<
RX14 >
i wouldn't know where to mention it though
19:30
<
RX14 >
maybe a section on the compiler commandline?
19:30
<
RX14 >
you should make an issue for that
19:31
<
FromGitter >
<andreaTP> I should probably a section mentioning formatter shards and the rest of the command line utils
19:32
<
FromGitter >
<andreaTP> That I'm not aware already ;-)
19:38
<
FromGitter >
<fridgerator> I just learned about formatter a couple of days ago
19:39
<
FromGitter >
<fridgerator> maybe in the 'Coding Style' in the docs?
19:39
<
FromGitter >
<fridgerator> would be a good place to put it?
19:41
<
BlaXpirit >
fridgerator, sounds good
19:41
<
BlaXpirit >
but yeah it's a tough choice. maybe not worth being put on top of that page, while at the bottom nobody's gonna find it
19:41
<
BlaXpirit >
oh well, i vote for top of page anyway
19:47
<
FromGitter >
<fridgerator> or in its own section within 'Conventions'? not sure
19:50
DTZUZU2 has joined #crystal-lang
19:56
dtzu has joined #crystal-lang
19:57
ponga has quit [Quit: Connection closed for inactivity]
20:06
<
FromGitter >
<raydf> Hi again
20:13
<
Yxhuvud >
I think it is a compiler bug.
20:13
<
FromGitter >
<raydf> ok, thanks, let's see if i can reduce it
20:16
bjz has joined #crystal-lang
20:25
mooe has joined #crystal-lang
20:32
soveran has joined #crystal-lang
20:37
soveran has quit [Ping timeout: 256 seconds]
20:49
<
splitty_ >
How would I stringify the content of a variable?
20:50
<
splitty_ >
If I pass 123 to a macro and use {{ value.stringify }} I'm getting "123", but if I pass a variable foo with a value of 123 to it, it prints x. Is there a way to resolve the variable before stringifying it?
20:53
<
FromGitter >
<luislavena> @splitty_ macros are resolved a compile time, not runtime. if you want to convert a value to a string, you might need to invoke `.to_s` method on that object/instance.
20:53
<
splitty_ >
Okay, thanks luislavena. I don't have to_s implemented yet, gonna have to do it differently then
20:55
<
FromGitter >
<luislavena> @splitty_ sometimes is best to show a piece of code and explain what are you trying to obtain as result for us to provide alternatives. I just based my response in your specific question, but perhaps are alternative ways to achieve the results.
20:56
<
splitty_ >
luislavena, I'm writing an operating system in Crystal. If that would've been possible, that would've saved me some time, but I guess I'll just have to implement to_s for Int then.
20:57
<
RX14 >
then you can use thing.class.name
20:58
<
RX14 >
it really doesn't seem to have any deps
20:59
<
splitty_ >
Oh that's pretty cool, thanks RX14
20:59
<
splitty_ >
RX14, I'm gonna copy it though. It could change in the future and that would unexpectedly break my kernel
21:00
<
RX14 >
yeah well so could the syntax
21:00
<
splitty_ >
hmm right
21:01
<
RX14 >
i guess copying it would make it sort of consistent
21:01
<
RX14 >
actually writing your own stdlib
21:01
<
RX14 >
like editing the require path to include your code as the stdlib
21:01
<
RX14 >
providing your own prelude.cr etc
21:02
<
RX14 >
actually maybe thats too much effort
21:02
<
RX14 >
and it probably doesn't give you too much gain
21:02
<
RX14 >
i'd just require it for now
21:02
<
splitty_ >
I also remove the inspect method, I'm not gonna need that for anything
21:03
<
splitty_ >
removed*
21:03
<
splitty_ >
I'm very happy with that prelude :D Not too bad for the second day
21:03
<
RX14 >
are you aiming for a specific architecture?
21:04
<
RX14 >
like microkernel or what
21:04
<
RX14 >
or is it too early
21:04
<
splitty_ >
Currently I'm only writing i686 code to simplify things. But the way the kernel is structured allows for implementing other architectures effortlessly.
21:04
<
splitty_ >
Oh I thought CPU architecture
21:04
<
splitty_ >
Actually I'm not sure yet
21:07
<
RX14 >
so what need to be done for 64bit support?
21:07
<
splitty_ >
I'd just have to get a basic 64-bit GDT going and enter long mode
21:08
<
splitty_ >
That's pretty easy to do
21:09
<
RX14 >
well i hope that once you're over this initial hump of sort of bootstrapping your stdlib to match up with the compiler's expectation of the old stdlib you can be productive in crystal
21:09
<
splitty_ >
yeah that would be cool ^^
21:17
<
splitty_ >
yeah that would be cool ^^
21:21
vivus-ignis has quit [Ping timeout: 260 seconds]
21:21
mgarciaisaia has quit [Quit: Leaving.]
21:24
<
FromGitter >
<petehuang> regular contributors: how do you all keep track of the various enhancements, bug fixes, RFCs in progress? issues section is kind of a catch-all right now, but hard to see the current status of everything
21:24
<
RX14 >
I just watch the issues section
21:24
<
RX14 >
and I guess remember it all
21:25
<
RX14 >
basically the answer is we don't plan
21:25
<
RX14 >
so there's no need
21:25
<
RX14 >
well I don't plan at least :/
21:27
<
RX14 >
if you want a more positive view, we'll be planning a new roadmap for 2017 soon
21:28
<
RX14 >
so then there's be some concrete goals
21:29
<
FromGitter >
<petehuang> i'm not necessarily concerned about planning, more about organizing: what enhancements are out there, which have recommended solutions (and just need implementation now), what bugs are unaddressed, etc.
21:29
<
splitty_ >
RX14, if I memset the 8 bytes of a UInt64 to 0_u8, the value should be 0_u64, right?
21:29
<
RX14 >
well thats basically the role of github issue tags @petehuang
21:30
<
RX14 >
splitty_, yes
21:30
<
splitty_ >
Something is really wrong here :D
21:31
<
splitty_ >
I'm calling this with a size of 8
21:31
<
splitty_ >
Then casting the result of a Pointer(UInt64)
21:31
<
splitty_ >
And then I'm checking assert_eq ptr.value, 0_u64
21:31
<
splitty_ >
Oh my god
21:31
<
splitty_ >
RX14, nevermind
21:32
<
splitty_ >
Yeah I'm stupid.
21:32
<
splitty_ >
My assert_eq macro was f*cked up
21:32
<
FromGitter >
<petehuang> @RX14 i hear you, but with 270+ issues isn't it hard for people (esp. new) to see what's going on?
21:33
<
FromGitter >
<petehuang> @RX14 maybe its because i'm new and it's not actually a problem
21:33
<
RX14 >
no it's a problem
21:33
<
RX14 >
and its not been solved
21:34
<
FromGitter >
<petehuang> and i also don't mean to just poke holes and not offer solutions, by the way. just don't want to overstep either
21:35
<
RX14 >
well it's not as bad as I make it out to be really
21:35
<
RX14 >
issues are pretty much like anarchy
21:35
<
RX14 >
"what do I want to fix today"
21:36
<
RX14 >
i think creating a tagging scheme and enforcing proper taggin of issues would be quite beneficial
21:36
<
RX14 >
for example having a bot to enforce issues get tagged on time
21:38
<
RX14 >
crystal's community is still pretty small
21:38
<
RX14 >
so it's just starting to be a problem
21:40
<
FromGitter >
<petehuang> understood...let me keep reading all the issues and get a deeper sense
21:41
<
FromGitter >
<petehuang> thanks for the input
21:50
<
splitty_ >
RX14, I'm having a bit of a problem with inline assembly
21:50
<
splitty_ >
fun outb(port : UInt16, val : UInt8)
21:50
<
splitty_ >
asm("outb %1, %0" :: "dN"(port), "a"(val))
21:50
<
splitty_ >
error: couldn't allocate input reg for constraint 'd'
21:52
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
21:52
<
RX14 >
I don't see the "d" constraint in the LLVM ir docs
21:53
<
splitty_ >
Oh yeah, thanks
21:53
<
splitty_ >
I was still thinking in terms of C inline assembly
21:54
<
splitty_ >
With m it works
21:55
p0p0pr37 has joined #crystal-lang
22:01
bjz has joined #crystal-lang
22:02
<
splitty_ >
RX14, I can't wrap my head around the LLVM inline assembly :D
22:02
<
splitty_ >
asm("outb $0, $1" :: "m"(port), "r"(val))
22:02
<
splitty_ >
m is a memory address
22:02
<
splitty_ >
r is a register
22:02
<
RX14 >
well i know nothing about inline assembly
22:02
<
RX14 >
so I can't help
22:03
<
RX14 >
all I know is where to direct you
22:07
<
splitty_ >
Oh I think I'll have to explicitly request the %al register
22:10
<
splitty_ >
Figured it out
22:12
DTZUZU has joined #crystal-lang
22:13
DTZUZU2 has quit [Ping timeout: 265 seconds]
22:21
<
RX14 >
I really should make issues for all the ideas I have for crystal
22:34
soveran has joined #crystal-lang
22:35
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
22:36
mooe has quit [Quit: Connection closed for inactivity]
22:39
soveran has quit [Ping timeout: 250 seconds]
22:48
bjz has joined #crystal-lang
22:50
<
FromGitter >
<petehuang> @RX14 you should!
22:51
<
RX14 >
i forgot it already...
23:00
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
23:08
bjz has joined #crystal-lang
23:13
DTZUZU has quit [Quit: WeeChat 1.5]
23:19
<
splitty_ >
RX14, if you have WhatsApp or Telegram, just send a memo to yourself whenever you have an idea
23:19
<
splitty_ >
Works pretty well
23:19
<
RX14 >
i have a trello
23:19
<
RX14 >
which is what I would use
23:19
<
splitty_ >
Yeah, that'd work too
23:20
<
splitty_ >
I personally find it to be kinda discouraging, having to write everything down
23:20
<
splitty_ >
So I just take my mobile, send a voice message to myself and explain to myself what I was gonna do
23:21
<
splitty_ >
Now that I think about it, that seems kinda weird
23:21
<
splitty_ >
But it works! :P
23:22
<
RX14 >
i find it harder to articulate out loud clearly outside a conversation
23:29
<
splitty_ >
Likewise. But if you start doing it then it'll quickly feel normal
23:29
<
splitty_ >
Good night :D
23:29
splitty_ is now known as [sleep]splitty_
23:45
vikaton has joined #crystal-lang
23:51
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
23:51
olek_poz has quit [Ping timeout: 264 seconds]
23:57
bjz has joined #crystal-lang
23:59
<
Papierkorb >
No one else uses sticky notes?