asterite changed the topic of #crystal-lang to: #crystal-lang The Crystal programming language | http://crystal-lang.org | Crystal 0.6.1 | Paste > 3 lines of text to https://gist.github.com | GH: https://github.com/manastech/crystal - Docs: http://crystal-lang.org/docs/ - API: http://crystal-lang.org/api/ - Logs: http://irclog.whitequark.org/crystal-lang
asterite has quit [Ping timeout: 246 seconds]
bcardiff has quit [Quit: Leaving.]
bcardiff has joined #crystal-lang
bcardiff has quit [Client Quit]
leafybasil has quit [Read error: No route to host]
leafybas_ has joined #crystal-lang
leafybas_ has quit [Read error: No route to host]
leafybasil has joined #crystal-lang
leafybasil has quit [Read error: No route to host]
leafybasil has joined #crystal-lang
leafybasil has quit [Read error: Connection reset by peer]
leafybasil has joined #crystal-lang
leafybasil has quit [Ping timeout: 255 seconds]
leafybasil has joined #crystal-lang
weskinner_mac has joined #crystal-lang
wanderer has quit [Quit: Page closed]
weskinner_mac has quit [Quit: weskinner_mac]
waj has joined #crystal-lang
waj has quit [Quit: Leaving.]
ismaelga has quit [Remote host closed the connection]
weskinner_mac has joined #crystal-lang
weskinner_mac has quit [Quit: weskinner_mac]
orliesaurus is now known as irelia
irelia is now known as orliesaurus
bcardiff has joined #crystal-lang
havenwood has quit [Remote host closed the connection]
bcardiff has quit [Quit: Leaving.]
ponga has quit [Remote host closed the connection]
bcardiff has joined #crystal-lang
bcardiff has quit [Quit: Leaving.]
ponga has joined #crystal-lang
ponga has quit [Ping timeout: 256 seconds]
havenwood has joined #crystal-lang
tymat has left #crystal-lang [#crystal-lang]
Ven has joined #crystal-lang
Ven has quit [Ping timeout: 252 seconds]
ponga has joined #crystal-lang
Ven has joined #crystal-lang
leafybasil has quit [Remote host closed the connection]
havenwood has quit [Remote host closed the connection]
leafybasil has joined #crystal-lang
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Ven has joined #crystal-lang
Ven has quit [Ping timeout: 246 seconds]
Ven has joined #crystal-lang
wanderer has joined #crystal-lang
<wanderer> if Object#tap yields itself and then returns itself, then the block is executed first, isn't it?
<jhass> executed first in relation to?
<wanderer> `def x(y); String.new(y).tap { LibC.free(y as Void*) }; end`
<wanderer> tap first yields, then returns itself
<wanderer> wouldn't that mean `y` is first freed, then returned?
<jhass> well yes, it can't yield after it returned because after it returned it doesn't run anymore
<jhass> that snippet should segfault sooner or later, yeah
<jhass> it frees dir
<jhass> after creating a string from it
<jhass> not the new string
<jhass> it's string = String.new(dir); free(dir); string
<wanderer> jhass: ah, ok
waj has joined #crystal-lang
Ven_ has joined #crystal-lang
Ven has quit [Ping timeout: 245 seconds]
Ven_ has quit [Ping timeout: 256 seconds]
Ven has joined #crystal-lang
waj has quit [Quit: Leaving.]
wanderer has quit [Quit: Page closed]
Ven has quit [Ping timeout: 255 seconds]
Ven has joined #crystal-lang
wanderer has joined #crystal-lang
waj has joined #crystal-lang
<wanderer> jhass: if I need a buffer for a c function, what's the best way? GC.malloc, a static array, ...?
<jhass> depends on what the buffer is for
<jhass> string, struct, ..?
<wanderer> string
<wanderer> UInt16*
<jhass> uh
<jhass> Pointer(UInt16).malloc I'd say
<jhass> or x :: UInt16[size] iirc
<jhass> 1) heap, 2) stack
<jhass> though the later isn't zero'd out, so careful
<wanderer> doesn't need to be, but should be on the heap
bcardiff has joined #crystal-lang
<wanderer> where exactly is the actual malloc of Pointer defined?
<jhass> probably one of the intrinsics
<jhass> it has its own AST node at least
<wanderer> so it's always zero initialized? because I wouldn't need the overhead
<jhass> Pointer.malloc is yes
<jhass> :: Type is not
<jhass> Struct#new is neither
<jhass> and that the later two aren't caused me several headaches already
<jhass> so I pay that overhead happily and would like to pay it for the later two too
<wanderer> something like UInt16* is builtin and becomes an instance of the pointer class, correct?
<jhass> UInt16* is just a shortcut for writing Pointer(UInt16), like String? is a shortcut to String|Nil
asterite has joined #crystal-lang
ismaelga has joined #crystal-lang
<asterite> Pointer.malloc is a built-in, but we could write in crystal like GC.malloc(sizeof(T)) or something like that, but it's not something we need to do right now
<asterite> By the way, Struct.new does initialize memory to zero. The only one that doesn't is ::
<wanderer> when I use `str = GC.malloc_atomic(bufsize.to_u32) as UInt8*` to get a buffer, how can I pass that buffer to a c function that expects a char *?
<wanderer> with str.address?
<asterite> str there is a Pointer(UInt8) (or UInt8*, it's the same)
<asterite> so you pass str directly
<asterite> char* is UInt8* in crystal
<wanderer> isn't it actually an object of the class Pointer?
<wanderer> how can I pass it directly then?
weskinner_work has joined #crystal-lang
<asterite> In Crystal everything looks like an object, but the internal representation can be anything we (the language writers) want
<asterite> a Pointer(UInt8) is the type of the value, but its representation is just a pointer
<asterite> like in C
havenwood has joined #crystal-lang
<wanderer> asterite: ah, information here is in general a little scattered
waj1 has joined #crystal-lang
<shadeslayer> asterite: curious, is there scope for a inotify class in crystal?
<asterite> what do you mean with "scope"?
<shadeslayer> as in, do you reckon it could go into the official repo
* shadeslayer was thinking of writing a module of sorts
<asterite> Maybe… I don't know anything about inotify
<asterite> But you can write it and once its done we can see if it can go in the std
waj has quit [Ping timeout: 245 seconds]
<asterite> :)
<jhass> if it goes into stdlib it should at least abstract away OS dependence IMO, inotify vs knotify or what it was called on mac?
<jhass> eh, not fsevent
<crystal-gh> [crystal] asterite pushed 1 new commit to master: http://git.io/hWkw
<crystal-gh> crystal/master 315aaf2 Ary Borenszweig: Fixed #488: Compiler falsely claims type mismatch in method invocation (involves array and union type)
<shadeslayer> mh
<shadeslayer> fswatch
<travis-ci> manastech/crystal#2153 (master - 315aaf2 : Ary Borenszweig): The build passed.
ponga has quit [Remote host closed the connection]
asterite has quit [Quit: Leaving.]
asterite has joined #crystal-lang
<wanderer> asterite: hi
<asterite> hi wanderer
<wanderer> I've got a question: the windows api doesn't support utf8, but only utf16, so much of the string code would look like: `ifdef darwin || linux status = LibC.stat(path, out stat) elsif windows status = LibC.stat(path.to_utf16, out stat) end`
<wanderer> overwriting `to_unsafe` for windows to always convert to utf16 isn't optimal, though, because there are still external libraries that support utf8, also for converting digits to a string the unicode api isn't needed
<asterite> Maybe another method, but I don't know what name we can use
<asterite> It's "utf-16 if windows otherwise self"
<asterite> We can have String#to_windows_unsafe or something like that
<asterite> Or maybe to_os_unsafe
<jhass> String#for_win32 ?
<asterite> so it would return self for linux and mac, and utf-16 for windows
<wanderer> it's regular utf16, again not specific to windows
<wanderer> I wouldn't label those things (stdcall, utf16, ...) with anything like "windows" as they're not specific to it
<jhass> how about LibC.stat LibC.convert_string(str)
<asterite> But LibC is a lib, it can't have methods
<asterite> I think to_os_unsafe is ok… or not?
<jhass> mh, yeah, just trying to namespace it to the lib
<asterite> Or just to_os
<wanderer> asterite: how would it work?
<jhass> it's essentially library specific, not OS specific
<wanderer> asterite: there are still ansi versions of the windows api, so they must not convert to utf16
<jhass> you can view the system calls still as a library
<asterite> def to_os_unsafe; ifdef windows; to_utf16.to_unsafe; else; to_unsafe; end; end
<jhass> from the conceptual standpoint
<jhass> yeah I don't think that's good
<jhass> that would imply all code on windows behaves that way
<asterite> But for to_os_unsafe you must invoke it manually, unlike to_unsafe
<jhass> while it's only the win32 api
<jhass> so I think scoping it to the library makes more sense than putting it into String
<asterite> What are the places where utf16 is used?
<wanderer> float.cr contains LibC.sprintf-calls, those could still be the ansi versions as there won't be any unicode involved
<jhass> you know what, a perfect place for those conversions would be my wrapper idea
<jhass> let's have an abstracted OS independent interface for that stuff
<jhass> and different implementations of it for each platform
<wanderer> for every winapi func that accepts string there is an ansi version and a wide one
<wanderer> the ansi version accepts UInt8*, but doesn't understand UTF8
<wanderer> the wide version uses UInt16* and UTF16
<asterite> So we should always use the wide one, right?
<wanderer> one could possibly label utf16 api funcs as @[string(utf16)] which overwrites to_unsafe to to_unsafe_utf16, if something like this is possible
<jhass> let's stdlib have no clue about platform specifics, wouldn't that be awesome?
<wanderer> as for the winapi, most likely always the wide-one
<wanderer> however when using other external libs on windows they might support utf8
<wanderer> so it's not "if windows then utf16"
ponga has joined #crystal-lang
<jhass> exactly, and thus String should have no knowledge about it
<jhass> String shouldn't care about the Win32 API
<jhass> that's not its job
<wanderer> yes, either there should be wrappers or the fun itself needs attributes, I guess
<wanderer> or nothing of this and it gets kind of verbose with something like this: def to_i ifdef darwin || linux LibC.atoi(cstr) elsif windows LibC.atoi(cstr.to_utf16) end end
<asterite> Or you can use the wrapper idea from jhass, and it becomes LibC.atoi(LibCWrappers.string(self))
<asterite> Or something like that, the name doesn't matter
<jhass> no
<jhass> CWrapper.atoi(self)
<wanderer> the atoi would be the wrapper
<asterite> And what would CWrapper.atoi do?
<wanderer> use either cstr or to_utf16
<jhass> linux_c_wrappers.cr: module CWrapper; def self.atoi(str) LibC.atoi(str); end; end;
<jhass> windows_c_wrappers.cr: module CWrapper; def self.atoi(str) LibC.atoi(str.to_utf16); end; end;
ponga has quit [Ping timeout: 245 seconds]
<jhass> plain, simple
<jhass> conditionally require either wrapper for the platform
<jhass> one switch in one place
<asterite> It had everything written twice, in my opinion
<jhass> and none of stdlib needs platform specifics
<jhass> and none of the wrappers need to know about other platforms
<asterite> From what I read, wanderer needs to pass a string as utf8 in linux/mac or utf16 in windows in some places
<jhass> you're making this too specific
<jhass> this is a general design problem
<wanderer> the general design problem is that you're kinda expecting POSIX everywhere
<wanderer> an overall solution would be a complete wrapper like jhass said or ifdefs in the specific code
<jhass> asterite: we probably could even stub out the linux and OS x wrappers with macro method_missing
<wanderer> the thing with the wrapper is, that it would add overhead and is sometimes not even needed, like in to_s in float.cr that uses sprintf which can stay the same on windows like I said, as there is no unicode needed
<jhass> and have some well placed macro code that generates the boilerplate on windows too
<wanderer> so a complete wrapper would be a nice solution, but also a kind of bloated one
<jhass> if llvm won't inline and optimize away single line functions that just pass along the args, I'll loose all my faith in it
<jhass> the runtime performance shouldn't be affected in most cases
<wanderer> yes, that's what I was guessing, too
<wanderer> could come otherwise, though
<asterite> Yes, llvm will definitely inline those
<asterite> and in non-release mode the performance hurt will be very minor
<jhass> so I think I made my point clear enough by now, there's not much point in further discussing, asterite and waj have to decide
<wanderer> what about something like @[uses_utf16_string] fun atoi(str : UInt16*) that makes strings use to_unsafe_utf16 rather than to_unsafe?
<jhass> if you want to litter stdlib with platform specific code and tons of ifdefs, go ahead
<jhass> I just would find that very very sad approach, but that's just my opinion
<wanderer> jhass: that was my argument yesterday, too, remember? :D
<asterite> I don't want to add an attribute just for this specific case
<asterite> Specially not if it can be done with what we have right now
<wanderer> however
<wanderer> I guess a problem with having a complete wrapper is the naming
<wanderer> for example printf only accepts ansi while wprintf uses utf16, if the func is now called CWrapper.printf and on windows it uses wprintf to emulate utf8 support
<wanderer> then how would the actual ansi func be called if needed?
<jhass> wanderer: LibC.printf and then that application code would become platform dependent
<jhass> it would be anyhow since there's no such distinction on other platforms
<jhass> so the only cases where it's needed, is already platform dependent
<wanderer> sorry, don't get what you mean atm
<jhass> there's no wprintf on other platforms, is there?
<wanderer> there is
<wanderer> it's c standard
<jhass> god
<wanderer> there's a difference between c standard and posix standard
<jhass> I hate posix
<jhass> and C
<wanderer> linux however uses utf8 so there no much use to wprintf
<wanderer> also on linux wprintf uses utf32, while on windows wprintf uses utf16
<jhass> I think my point still holds though
<jhass> if you need to care about these differences, your code is already inherently platform dependent
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jhass> so you can just bypass the wrapper without loosing anything
<wanderer> on windows there is atoi (ansi) and wtoi (utf16, windows specific)
<jhass> that defies my point how?
<wanderer> I still didn't get how you would solve this
<wanderer> you could make atoi on windows use wtoi, so you just have CWrappers.atoi, but that hides the actual atoi on windows
<wanderer> please explain your solution later again for me, gotta go
<wanderer> bye
wanderer has quit [Quit: Page closed]
<asterite> I think using an ifdef is simpler :)
<asterite> Once we get to the point of having 100 ifdef, then we can have a better idea of how to refactor
<asterite> I don't understand why is he concerned with hiding "atoi" or something like that :(
<jhass> asterite: honestly, we will get to that point
<jhass> you're only increasing the pain of implementing a proper design by delaying it
<jhass> both of you think in specific
<jhass> s
<jhass> this is wrong
<jhass> it's a general design problem
<asterite> How do they solve this in ruby?
<jhass> which function behaves how is completely irrelevant
<jhass> tons of littered ifdefs
<jhass> it's horrible to read
<jhass> + a good deal of defines and stuff
<asterite> But 'amount of ruby users vs. amount of ruby core developers is huge
<asterite> I also think your wrapper idea is ok, I don't know why wanderer doesn't like it
<asterite> It adds a small overhead, but it doesn't matter because you will ship code built in release mode anyway
<asterite> And we could even improve the compiler to inline such calls even in non-release mode
<jhass> just decide it, he'll go with it
<jhass> I'll write up a clean gist to demo
<asterite> That module is full of `when defined`
<jhass> yes, it's horrible
<jhass> it's two functions in one
<asterite> I think another approach could be to have those methods be in "dir/linux.cr" and "dir/windows.cr"
<jhass> you permanently have to refocus on what code you want to follow this time
<asterite> and dir does ifdef windows; require "dir/windows"; end
<jhass> yes, I think I'm saying this all the time
<asterite> but without a wrapper class
<jhass> oh, you mean to implement the stdlib twice?
<jhass> I think that won't work out
<asterite> It's just once for each OS, but only do this for the methods that are different
<jhass> for the most time it's code; code; code; specific-call; code; code;
<asterite> Mmm… I'm not sure about that
<asterite> but only because I don't know about the windows api
<jhass> well, there's at least a huge potential for that
<asterite> Looking at that nimrod module, it looks like things in linux and windows are quite different
<jhass> again, this is not to be decided in the specific
<jhass> it needs a system design
<asterite> In the beginning we didn't have ifdef, and you'd have to do `require "…" if windows`
<asterite> so that forced you to split os-specific things in different files, but it was annoying most of the time
<jhass> platform specific stuff is annoying
<jhass> any solution will be annoying in some way
<asterite> Yes :(
<asterite> linux and mac are similar in many ways, but windows is very different
<asterite> I'm sooo lazy to make crystal work in windows
<jhass> you don't have to, but you have to decide the design
<asterite> and at least waj's idea is to use crystal for severs, so I don't think windows is of interest to him (and not really for me either)
eli-se has joined #crystal-lang
<eli-se> hi
waj has joined #crystal-lang
waj1 has quit [Ping timeout: 256 seconds]
<jhass> asterite: https://gist.github.com/jhass/cbc509e8ed1025b22a70 think that's clear enough?
<jhass> asterite: argh, didn't save some files, please refresh
<asterite> I think it looks pretty clean :)
<jhass> !memo wanderer please see https://gist.github.com/jhass/cbc509e8ed1025b22a70 (also note the comment below)
<DeBot> jhass: Added memo for wanderer.
<asterite> Wow! And that will say that to wanderer once he connects?
<jhass> yes
<jhass> !memo /asterite[1_]/ that is if you say something or join ;)
<DeBot> jhass: Added memo for /asterite[1_]/.
<jhass> you'll see next time you fail to gain your nick :P
<asterite> :)
<asterite> !memo asterite Hello!
<DeBot> asterite: You can't leave memos for yourself..
<asterite> :(
<jhass> ugh, missing dot there :P
<asterite> But those are the most useful!
<asterite> (just kidding)
eli-se has quit [Quit: Leaving...]
<asterite> !hangman
<asterite> :(
waj1 has joined #crystal-lang
<asterite> It comes and goes?
<jhass> it needs to be directed at the bot for this one
<jhass> DeBot: !hangman
<DeBot> _________ [] 0/12
<asterite> Ah, ok
<asterite> DeBot: a
<DeBot> _A____A__ [] 0/12
<asterite> DeBot: e
<DeBot> _A____A_E [] 0/12
<asterite> DeBot: l
<DeBot> _A____A_E [L] 1/12
<asterite> DeBot: m
<DeBot> _A____A_E [LM] 2/12
<asterite> DeBot: c
<DeBot> CA____A_E [LM] 2/12
<asterite> DeBot: b
<DeBot> CA____A_E [LMB] 3/12
<DeBot> CA____A_E [LMBG] 4/12
<asterite> DeBot: g
<asterite> DeBot: n
<DeBot> CAN___A_E [LMBG] 4/12
<asterite> DeBot: d
<DeBot> CAND_DA_E [LMBG] 4/12
<asterite> DeBot: i
<DeBot> CANDIDA_E [LMBG] 4/12
<asterite> DeBot: t
<DeBot> CANDIDATE [LMBG] 4/12 You won!
waj has quit [Ping timeout: 264 seconds]
ponga has joined #crystal-lang
havenn has joined #crystal-lang
shadeslayer has quit [Ping timeout: 256 seconds]
havenwood has quit [Ping timeout: 252 seconds]
ponga has quit [Ping timeout: 256 seconds]
shadeslayer has joined #crystal-lang
asterite has quit [Quit: Leaving.]
eli-se has joined #crystal-lang
weskinner_work has quit [Ping timeout: 264 seconds]
weskinner_work has joined #crystal-lang
bcardiff1 has joined #crystal-lang
shama has joined #crystal-lang
bcardiff has quit [Ping timeout: 252 seconds]
eli-se has quit [Quit: Leaving...]
bcardiff1 has quit [Quit: Leaving.]
ismaelga has quit [Remote host closed the connection]
leafybasil has quit [Remote host closed the connection]
eli-se has joined #crystal-lang
weskinner_work has quit [Ping timeout: 264 seconds]
weskinner_work has joined #crystal-lang
<crystal-gh> [crystal] Exilor opened pull request #489: Fixed Array#| (master...master) http://git.io/h81Q
leafybasil has joined #crystal-lang
leafybasil has quit [Remote host closed the connection]
leafybasil has joined #crystal-lang
leafybasil has quit [Remote host closed the connection]
ponga has joined #crystal-lang
eli-se has quit [Quit: Leaving...]
ponga has quit [Ping timeout: 244 seconds]
havenn is now known as havenwood
weskinner_work has quit [Remote host closed the connection]
weskinner_work has joined #crystal-lang
eli-se has joined #crystal-lang
sferik has joined #crystal-lang
leafybasil has joined #crystal-lang
leafybasil has quit [Ping timeout: 252 seconds]
bcardiff has joined #crystal-lang
bcardiff has quit [Quit: Leaving.]
bcardiff has joined #crystal-lang
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bcardiff has quit [Quit: Leaving.]
ponga has joined #crystal-lang
sferik has joined #crystal-lang
leafybasil has joined #crystal-lang
<havenwood> I've always thought it was odd that Ruby's #each_with_index wasn't named #map_with_index. And the same with #each_with_object, #each_slice, etcetera. It seems like the #each versions should return the receiver, or an Enumerator if no block is given--like #each.
<jhass> #map should return the block return values though, not some argument
<jhass> and also .each_with_object(some_expensive_method_call) {|item, i_saved_an_external_local_and_a_closure| item.process i_saved... } is a valid usecase
<havenwood> jhass: well, it makes more sense to me for map to be mapping to a provided object than for each to be mapping to anything
<jhass> dunno, I don't think about them like mapping
<havenwood> jhass: aren't they more mapping than each? or do you think not?
<jhass> more like efficient versions of .slices(3).each, .with_object(x).each etc
<havenwood> i guess that's the logic, each.with_index
<eli-se> each.zip(1..Inf) :P
<eli-se> or rather the other way around
asterite has joined #crystal-lang
wanderer has joined #crystal-lang
asterite1 has joined #crystal-lang
<crystal-gh> [crystal] asterite closed pull request #489: Fixed Array#| (master...master) http://git.io/h81Q
asterite2 has joined #crystal-lang
asterite has quit [Ping timeout: 244 seconds]
asterite1 has quit [Ping timeout: 246 seconds]
asterite2 has quit [Ping timeout: 264 seconds]
asterite has joined #crystal-lang
<wanderer> asterite: hi again
asterite1 has joined #crystal-lang
asterite has quit [Ping timeout: 256 seconds]
orliesaurus has left #crystal-lang [#crystal-lang]
<crystal-gh> [crystal] asterite pushed 1 new commit to master: http://git.io/h4De
<crystal-gh> crystal/master b73b155 Ary Borenszweig: Fixed Array#&
<wanderer> jhass: yes, you would actually need to create a new low level api that gets then implemented for linux, mac, windows and maybe more, with that api being not bound to any particular system like posix
<jhass> exactly
<wanderer> I then wouldn't call it CWrapper as it would be more of a crystal_low_level_api
<wanderer> also if you go as far as coming up with a system/low level api to abstract away the actual OS, you would first need an intersection set
<travis-ci> manastech/crystal#2155 (master - adcd634 : Ary Borenszweig): The build passed.
weskinner_work has quit [Ping timeout: 246 seconds]
<wanderer> e.g. LibC.fork would reside outside of that low level api as fork() is not in such subset
<wanderer> it'd be the nicest solution, but requires putting work into coming up with a sane api construct, ruby itself seems to use detours or have ifdefs in its functions like D and Nim
<wanderer> simply like `def xyz; ifdef darwin || linux; stat(...); elsif windows; GetFileAttributes(...); end; end;`
<jhass> yes, and I find this increasingly hard to read
<jhass> I'm not sure if you really need to design the complete API upfront
<wanderer> it is, both approaches have their pros and cons
<jhass> you would do the ifdef stuff as you go too
<jhass> so why not add the wrappers as needed
<wanderer> one could also add an attribute that overwrites the to_unsafe like @[new_unsafe=to_unsafe_utf16] and if arguments passed to that fun have a method called to_unsafe_utf16, it is then called instead, this would reduce ifdefs when linux and windows share the same codebase which goes for the complete c standard routines
waj1 has quit [Quit: Leaving.]
<wanderer> wait, no this is bad as it would introduce the problem I mentioned earlier with shadowing the windows ansi functions. for sharing the same codebase, the funs also have to have the same names, so it needs to be LibC.atoi on linux and on Windows, while on Windows it would need to be fun atoi = _wtoi, so both calls would look the same, then however, the ansi atoi on windows is shadowed
<jhass> wanderer: no
<jhass> that's just in my example
<travis-ci> manastech/crystal#2156 (master - b73b155 : Ary Borenszweig): The build passed.
<jhass> wanderer: you can bind them in the platform specific files instead
<wanderer> jhass: I meant my suggested approach just now is bugged
<jhass> oh, sorry
<wanderer> when you have a wrapper this wouldn't be a problem
<jhass> was following another channel and didn't read up, sorry
weskinner_work has joined #crystal-lang
<wanderer> being able to overwrite the to_unsafe method would be handy, though, when defining utf16 functions for windows or some other platform, everytime you call them with a string you'd need to invoke .to_utf16, it'd be convenient if there was a way to automate this
<wanderer> on per fun basis
<jhass> macro utf16_wrapper name; def {{name.id}}(arg); LibC.{{name.id}}(arg.to_utf16); end; end; + proper argument handling but you get the idea
weskinner_work has quit [Ping timeout: 244 seconds]
shama has quit [Quit: (╯°□°)╯︵ɐɯɐɥs]
eli-se has quit [Quit: Leaving...]
sferik_ has joined #crystal-lang
sferik has quit [Ping timeout: 264 seconds]
bcardiff has joined #crystal-lang
ismaelga has joined #crystal-lang
ismaelga has quit [Client Quit]
ismaelga has joined #crystal-lang