<wanderer_>
just open the directory in cmd and execute `bin\crystal build src\compiler\crystal.cr --cross-compile "windows x86" --single-module --target "i686-pc-win32-gnu" -o bin\crystal_win`
<asterite>
I'll try now :)
<asterite>
Tried it, it crashes
<wanderer_>
with the same error?
<wanderer_>
Unable to create directory...
<asterite>
Nah, I get a popup saying it crashed
<asterite>
in msvcrt.dll
<wanderer_>
lol, again?
<wanderer_>
you had that last time as well, I couldn't reproduce it, though
<asterite>
But if I compile a "foo.cr" with "puts 1" it works (doesn't crash)
<asterite>
I'll try commenting that line now
<asterite>
Maybe I get that popup becuase it's windows XP
<wanderer_>
yes, but I've tried it in a WinXP VM, too
<asterite>
Well, with that line commented it doesn't crash... so far
<wanderer_>
everything worked like on Win7 for me
<asterite>
it's taking some time, I guess to generate the llvm code
<asterite>
So what's the error you are seeing?
<wanderer_>
the one from above "Unable to create directory"
<wanderer_>
I guess I know now how to fix it, however, I still don't know why it's actually not working (again I assume it's some macro "magic")
<wanderer_>
could you change `output_dir = ...` in compiler.cr to `output_dir = ".crystal\\#{sources.first.filename[3..-1]}"`?
<asterite>
Aaaaah... the compiler uses ECR!
<wanderer_>
yes, that's what I said earlier :P
<asterite>
That invokes another program and runs it, so that will never work in windows unless the windows compiler can create programs
<asterite>
Oh, sorry, I just now realize it
<asterite>
So I guess for now you'll have to comment that line until the compiler fully works on windows
* asterite
blushes
<asterite>
Good then :)
<asterite>
By the way, did you learn git already? :-)
<asterite>
You will see it explains how "run" works inside macros, and just below it ECR is explained
<asterite>
So basically at compile-time we execute a program that parses the ECR and produces crystal code that appends that content to an IO, mixed with crystal code
<wanderer_>
so the compiler executes the program which executes the compiler?
<wanderer_>
or... also why is it only invoked when `Crystal.generate_docs` is not commented out? I had a `puts` prior to generate_docs which wasn't executed
weskinner_work has joined #crystal-lang
weskinner_work has quit [Ping timeout: 250 seconds]
<wanderer_>
asterite: quick side question, is something like this possible: `bla = Bla.new; def bla.x; end;`?
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: http://git.io/ve3vv
<riceandbeans>
instead of making a file or passing an argument to something else, like separation of concerns, it lets you gather your concerns on one spot and fret over them by throwing objects at everything?
<riceandbeans>
is that really a good thing?
<jhass>
huh?
<jhass>
it lets you serialize and deserialze arbitrary objects, that's all
<wanderer_>
jhass: hey, wouldn't a String#[]?(index : Int) be good, too? apparently there is none yet. also do you think an UTF-16/-32 String in the language is of any use or just some convert-functions that return UInt16* and UInt32* for interfacing with libs?
<jhass>
String#[]?(index) sounds good
<jhass>
whether I'd like an encoding aware string or rather only encoding aware IO I'm not sure
<jhass>
I think I'd actually tend to do encoding aware IO
<jhass>
like you set an encoding to an IO and it converts from/to UTF-8
<wanderer_>
I'm slowly getting into crystal and I've noticed there are almost always a function that raises and a counter-part which returns nil instead, but as for String#[]?(index) there's only the first
<jhass>
though I'm not sure if I'm missing a usecase for having an encoding aware String
<wanderer_>
so only one String that is always UTF-8?
<jhass>
as said, I think I'd like that
<jhass>
and maybe have String#encode that returns a Slice
<jhass>
And String.new that takes a slice and an encoding
<jhass>
(or pointer)
<jhass>
but then again as said I might be missing a usecase for keeping the string internal buffer in a specific encoding
<wanderer_>
the winapi needs UTF-16, so far I've added a String#to_utf16 returning UInt16*, but just for dirty porting as of now, also a String#new(UInt16*), and I was thinking how it should actually be modelled when the port is working
<jhass>
yeah, I think I'd like to keep the types as UInt8*
<jhass>
the buffers that is
<jhass>
encoding is interprentation of data, not representation
<jhass>
er, *interpretation
<shadeslayer>
is there some doc that teaches you how to use the Enumerable module with classes?
<jhass>
shadeslayer: you define an each method that yields the items of the collection and include Enumerable, that's it
<wanderer_>
hm, yes, but for interfacing you kinda need to representate it, like `fun winapi_func(bla : UInt16*)` for proper type-checking, so you'd also need the converting func to return that type
<jhass>
time from fixing bugs and adding awesome features :P
<shadeslayer>
Ok, I have to leave, cya tomorrow :D
<shadeslayer>
jhass: yeah I totally understand
<jhass>
cool, cya
jua__ has joined #crystal-lang
jua_ has quit [Ping timeout: 264 seconds]
jua__ is now known as jua_
<wanderer_>
jhass: hm, what exactly do you mean with encoding is interpretation? you can't just have an UTF-8 string passed to a function expecting an UTF-16 string, if you mean something like that
<wanderer_>
you have to convert the UTF-8 string
<jhass>
encoding is interpretation of a a byte sequence
<jhass>
not how it is stored
<jhass>
converting a byte sequence from one encoding into another will alter it, but it doesn't define that the result must be stored differently
<wanderer_>
not making it have another type is unsafe, though, rather C-like, Crystal is type-safe so an UTF-16 string should have another type, also it'd get accessed word-wise, so it should have an Int16 type
<jhass>
no
<wanderer_>
hm?
<jhass>
I'm sorry but that is not what encoding is about
<jhass>
it simply is not
<jhass>
that the windows API wants a UInt16* pointer to a UTF-16 encoded byte sequence doesn't prove anything in that regard
<jhass>
Let's take Ruby to study this on a high level
<wanderer_>
hm, might be the case, however, you would lose type-safety
<jhass>
no, you wouldn't
<jhass>
encodings actually have a common interface
<jhass>
called codepoints
<jhass>
which is the numerical value of a character
<jhass>
an encoding defines how a sequence of these numerical values is _encoded_ into a byte sequence
<jhass>
how that byte sequence is represented in memory is irrelevant to encodings
<jhass>
it changes how the byte sequence underlying the string is interpreted
<jhass>
it will _not_ change the byte sequence or its representation in memory
<jhass>
so the windows API taking a UInt16* is actually taking a decoded Unicode codepoint array and just being unable to take the Unicode pages that have values > UInt16
<jhass>
UTF-16 is how a Unicode codepoint is encoded into a byte sequence, UTF-8 is how a Unicode codepoint is encoded into a byte sequence, UTF-32 is how a Unicode codepoint is encoded into a byte sequence, ASCII is how a ASCII codepoint is encoded into a byte sequence, ...
<jhass>
you get the pattern
bcardiff has joined #crystal-lang
havenn has joined #crystal-lang
havenwood has quit [Ping timeout: 246 seconds]
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: http://git.io/venBC
<crystal-gh>
crystal/master a53f2ad Ary Borenszweig: Added String#[]?(index : Int) and some other helper methods
asterite has joined #crystal-lang
<asterite>
jhass: The Node code with the left and right, with each and Enumerable... that's one of the things that Crystal can't do right now :(
<asterite>
We will need to make the block inference a bit better, to determine if a block is effectively captured or not
<asterite>
I'm telling you because you seem to be around here more than me and always give super good answers, so here's one more answer to your repertoire :-)
<asterite>
It's something that we plan to tackle later on...
asterite has quit [Client Quit]
jua_ has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
<travis-ci>
manastech/crystal#2185 (master - a53f2ad : Ary Borenszweig): The build was broken.
<wanderer_>
but code points are mapped to code units and UTF-16 has word sized code units, so isn't it rather a word sequence instead of a byte sequence?
<jhass>
mh, haven't head the term code unit yet
asterite has joined #crystal-lang
<jhass>
ah well, that's just an abstraction step in the process apparently
<jhass>
I'm talking about the general definition of what a encoding is
<jhass>
and that is how to transform a byte sequence into a sequence of codepoints
<jhass>
how that transformation happens is not too relevant
<asterite>
Encodings is something that we definitely need to support. It'll be similar to how they do it in Java and C# I guess. In those, Strings are always encoded as UTF-16, and I think encoding is provided in the IO classes. We will have to do the same, I think, or just provided an EncodedIO of some sort. But I think waj has a better mental model of all of this :-)
<jhass>
I've been thinking about this and I think having a it in a third class could be interesting to investigate
<asterite>
wanderer_: I saw your questions about PPID and others, but I think it'll be better if you leave those questions as GitHub issues... otherwise I have to use a txt file with tasks (which I do! but it's not very ordered and I might forget those)
<jhass>
something like StringSlice (needs a better name)
<jhass>
which would be buffer with an associated encoding
<jhass>
it wouldn't provide any of the String functions like #[], #gsub, #count or so
<jhass>
but it would have #encode, #force_encoding, perhaps #decode if it makes sense
<jhass>
String#encode would simply delegate to it, like StringSlice.new(buffer, length, Encoding::UTF_8).encode(encoding)
<jhass>
just a rough idea
<jhass>
because having a datatype that represents a buffer with an encoding is actually useful
<jhass>
so you can ask it what encoding it is and do things upon that
<jhass>
thing HTTP
<jhass>
where the header defines the bodies encoding
<jhass>
*think
<jhass>
but I also would see it useful to take all that logic out of String to make it easier to reason about and to make the implementations of the various String methods simpler
<asterite>
Yes. I'm also thinking about something like: f = File.open("...", "r"). encoder = Encoder.new(f, "UTF-16"); # default output is UTF-8; encoder.read # would decode from UTF-16 to UTF-8
<asterite>
Or something like that, maybe...
<jhass>
well, I'm thinking of more than a pure utility class that turns one UInt8* into another one
<jhass>
keeping the encoding associated to the buffer instead
<jhass>
so you can ask it what it is
<jhass>
another thing a friend of mine hinted to think about are collations btw
<asterite>
So many things...
<asterite>
In the end it takes more time to implement encodings and collations correctly than to make a language
<jhass>
hehe
<wanderer_>
unicode is huge and complex
<jhass>
actually not so much, encodings as topic is complex
<jhass>
but don't get me started on timezones :P
<wanderer_>
simple upcase and strcmp in unicode isn't that simple anymore