non-aristotelian has quit [Quit: non-aristotelian]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
Renich_ has joined #crystal-lang
Renich_ has quit [Client Quit]
Renich has quit [Ping timeout: 246 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
<FromGitter>
<rabingaire> One stupid question guys
<FromGitter>
<rabingaire> Laxer and Parser are written by hand right ??
<FromGitter>
<rabingaire> it's only machine code that is generated by LLVM
<oprypin>
rabingaire: yes
fifr has quit [Ping timeout: 240 seconds]
fifr has joined #crystal-lang
DTZUZO has quit [Ping timeout: 240 seconds]
_whitelogger has joined #crystal-lang
DTZUZO has joined #crystal-lang
DTZUZO has quit [Quit: WeeChat 2.0]
DTZUZO has joined #crystal-lang
ua has quit [Remote host closed the connection]
ashirase has quit [Ping timeout: 250 seconds]
druonysus has quit [Ping timeout: 268 seconds]
ashirase has joined #crystal-lang
<jokke>
*Lexer
<jokke>
8)
ua has joined #crystal-lang
<FromGitter>
<greenbigfrog> Thanks for your help @oprypin @dscottboggs_gitlab and @j8r yesterday
<FromGitter>
<greenbigfrog> If I compile something locally and then try running that binary on my VPS it fails with `error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory` ⏎ If I build it on the VPS it'll run without any issues
<FromGitter>
<greenbigfrog> libpcre seams to be in `/lib/x86_64-linux-gnu/` on the debian machine
<FromGitter>
<greenbigfrog> linking libpcre fixes it, only that it then can't find the next library... isn't there an easier way?
<FromGitter>
<bew> Try running the binary on the remote with `LD_LIBRARY_PATH=/lib/x86_64-linux-gnu <binary>`
<FromGitter>
<bew> This will make the library loader search this folder for libs
Yxhuvud has quit [Quit: No Ping reply in 180 seconds.]
<FromGitter>
<greenbigfrog> The issue is that the versions slightly differ between arch and debian
<FromGitter>
<greenbigfrog> linking the missing libs works ⏎ Still missing `/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by ./website)` though
<FromGitter>
<greenbigfrog> currently thinking about simply using docker or sth to build it...
<FromGitter>
<greenbigfrog> `openssl => 1.1.0f-3+deb9u2` and `libssl1.1 => 1.1.0f-3+deb9u2)` are already installed
<FromGitter>
<j8r> @greenbigfrog that's normal: you have builded a dynamically linked binary, and then you want to run it in another system
<FromGitter>
<j8r> dynamically linking means using exactly the same versions
<FromGitter>
<greenbigfrog> ah. ok
<FromGitter>
<greenbigfrog> any way I can still compile local and run on the other system?
<FromGitter>
<j8r> both OS needs to be exactly the same, at least for the libs
<FromGitter>
<j8r> You want static linking then
<FromGitter>
<greenbigfrog> argh. ok
<FromGitter>
<j8r> Only Alpine is trully supported (it might work on Debian, haven't tested)
<FromGitter>
<greenbigfrog> I wad mainly wanting to do this to use travis for continous deployment. So simply building the executable in the docker image, and then running in an alpine container isn't that big of an addition :)
<jokke>
greenbigfrog: why don't you build it in alpine?
<FromGitter>
<j8r> @greenbigfrog better to either: ⏎ ⏎ 1) build an Alpine image with the executable, and run specs on the built one ⏎ 2) or build a statically linked binary, and put it on a from scratch image [https://gitter.im/crystal-lang/crystal?at=5bffde8ca115c91ef7af84b7]
<jokke>
yeah scratch is nice
<FromGitter>
<greenbigfrog> That's what I meant :)
<FromGitter>
<greenbigfrog> wdym with `scratch image`?
<jokke>
it's an image without anything
<jokke>
all you put there is all you have
<jokke>
so if you statically link your binary (which you can if you build in alpine), it's all you need to run your app
<jokke>
greenbigfrog: so docker can do so called multi-stage builds
<FromGitter>
<greenbigfrog> `Raises IndexError if trying to set an element outside the array's range.`
<jokke>
note the two FROM statements in the dockerfile
<FromGitter>
<greenbigfrog> oh. wait. because the size of arrays is fixed at compile time in the code I gave above
<jokke>
yeah well `a << "hi"` would fix your problem there
<FromGitter>
<greenbigfrog> thanks for all your help. I think I'll be able to figure it out from here 😄 Gotta refresh my docker knowledge first though :)
<FromGitter>
<j8r> yeah, the arrays aren't sparse in Crystal
<FromGitter>
<j8r> Maybe crystal could have this, don't know the use case
<FromGitter>
<j8r> i think it's a bad idea
<jokke>
me too
<jokke>
it's very confusing]
<FromGitter>
<greenbigfrog> @j8r why is crystal-alpine stuck at 0.26.0?
<jokke>
because of an issue
<jokke>
which is unresolved
<jokke>
they will skip 0.27.0
<jokke>
it's fixed in master but you'll have to wait for the release of 0.27.1
<FromGitter>
<greenbigfrog> argh...
<jokke>
do you use 0.27.0 syntax?
<jokke>
or something else that isn't backwards compatible?
<jokke>
i think there were no syntax changes tbh but some apis have changed
<FromGitter>
<greenbigfrog> My code isn't backwards compatible rly...
<jokke>
which is why i'm in strong support of deprecating things before removing them
<jokke>
super annoying
<FromGitter>
<greenbigfrog> I think I'll just delay the continous deployment idea till 0.27.1 is released 😄
<jokke>
heh yeah :)
<jokke>
i have a branch lying around which changes things to be 0.27.x compliant but i can't merge it for this reason. It also forces me to develop in docker
<jokke>
very frustrating all in all
<jokke>
i mean, yeah, crystal hasn't hit 1.0 yet but deprecating things before removing them alltogether wouldn't be so hard to do.
return0e has quit []
<z64>
speaking of deprecating things.. has there been any recent discussion about the future of json.mapping, etc? i'm aware that json::serializable still doesn't provide the best solution in all cases, but it would be good to know if json.mapping's days were officially numbered
<z64>
or alternatively, the security of using json::serializable
<jhass>
I don't think it's fully decided yet
<jhass>
maybe we even keep both
<jokke>
security?
<jokke>
i love json serializable
Renich has joined #crystal-lang
<z64>
well, my two cents is i think it's too complicated to understand when you should use one or ther other.. maybe its just "use serializable if you need composition", but i don't think thats a strong enough guide. one could be removed to a shard to be maintained on its own. i think ideally, and i've read this from some others, we should have a means to describe object mappings between any format - json,
<z64>
binary - all with the same interface, configured by annotations specific to the format
<jokke>
yeah that'd be ideal
<z64>
jokke: by "security" i mean an answer like "serializable *definitely* won't be removed, and its safe to migrate a large code base to use it"
<jokke>
ah ok
<jokke>
why would it be removed?
<jokke>
thought that was only on the table for mapping
<z64>
right, it seems that way - thats all i was asking, since the discussion about what is going to stay or go is scattered between many issues
<FromGitter>
<j8r> I think this whole opinionated serialization things should be in external shards
<FromGitter>
<j8r> It would be ok to have a really basic mapping solution in the stdlib, which is extensible, that's it
<FromGitter>
<j8r> e.g. Rust has serde for this
<z64>
yeah. there was talk before too about making more use of github.com/crystal-lang for "blessed" shards, i would love to see us make more use of that soon for unstable features, that get graduated into the stdlib
<z64>
serde, right
<FromGitter>
<j8r> 💯 agree z64
<z64>
one project i maintain right now has 98 json.mapping - just wanted to ask for some confidence before spending an evening or two on it :)
<FromGitter>
<drum445> would be a shame to see either removed tbh. Crystal fits nicely as a webservice programming language and having such an accessible json library built in is a big deal
<FromGitter>
<drum445> Or the replacement would need to also go from object -> json and json -> object just as easily. Golang offers this in stdlib
<z64>
yeah for sure - i think everyone is on the same page there :) we just want to optimize the API between flexibility, redundancy (having multiple mapping solutions) and any drawbacks
<FromGitter>
<drum445> Yep, makes a lot of sense. I'm just like you, have a few projects that rely on json.mapping ;)
<FromGitter>
<DRVTiny> I want to implement integraion with the Crystal event loop (scheduller) for my shard. Where can i look for some fine examples of such integration?
<FromGitter>
<drum445> @Blacksmoke16 indeed
Renich_ has joined #crystal-lang
Renich has quit [Ping timeout: 245 seconds]
Renich_ is now known as Renich
<jhass>
DRVTiny: stdlib? :P
<jhass>
what's your shard doing?
<FromGitter>
<kinxer> Is there a way to access the specific class of `T` (or the equivalent) for an instance of a generic class (other than parsing the class name)? For example, could I find out what the class of an Array element is?
<jhass>
at runtime or at compile time?
<jhass>
also to do what?
<FromGitter>
<kinxer> I'm just trying to see if I can extract some similar subclass methods into their abstract superclass. Each subclass has an ivar Array with an abstractly required getter, but the different classes don't necessarily have the same kind of elements in their array. This isn't crucial; I'm mostly just curious if I can do that, either at compile time or runtime.
<FromGitter>
<kinxer> Also, the abstractly required getter does specify that it returns an Array.
<FromGitter>
<kinxer> And I'm using "required" non-technically.
Yxhuvud has joined #crystal-lang
<jhass>
so just make the base generic and move the array there? abstract class Base(T); @items : Array(T); protected def add_item(item : T); @items << item; end; yada yada?
<FromGitter>
<kinxer> Yeah, that makes sense. I just don't want to do that. :P Supposing I had a good reason not to do that, is there a way to access the Array element's class anyway?
<jhass>
I think you're asking for a generic solution for a specific problem you have
<jhass>
of course such doesn't exist
<FromGitter>
<kinxer> That's fair. Thanks for your help. :)
<jhass>
describe your specific problem better
<jhass>
and we may be able to suggest idiomatic solutions
<jhass>
awesome if it illustrates why you wouldn't want my first suggestion :P
<FromGitter>
<kinxer> Oh, it probably won't. I was being serious when I said I "just" don't want to do that. My preference against it is primarily aesthetic, unless it would introduce issues for the custom JSON serialization and deserialization I'm doing (which I'm not including in the example, unless you specifically want it).
<FromGitter>
<drum445> > *<jhass>* I think you're asking for a generic solution for a specific problem you have ⏎ Applies to a lot of questions i ask tbh ;)
<FromGitter>
<drum445> Applies to a lot of questions i ask tbh ;)
<jhass>
Ah I just rephreased XY
<jhass>
?xy
<DeBot>
it seems like you are asking for a specific solution to a problem, instead of asking about your problem. This often leads to bad solutions and increases frustration for you and those trying to help you. More: http://meta.stackexchange.com/a/66378
<jhass>
rephrased even
<FromGitter>
<kinxer> I'm asking primarily for my own knowledge for the future, not because I have a problem I can't solve sufficiently. I would be more specific if I needed a specific answer, but I want a more general answer about what is possible and reasonable within Crystal. But give me a sec and I'll have a play link for you.
<FromGitter>
<kinxer> Okay, so we'll say that this code (https://play.crystal-lang.org/#/r/5nma) is indicative of what I have now. I want to extract `self.type_of_value` to the abstract superclass. I thought I could use generics like this (https://play.crystal-lang.org/#/r/5nmd), but apparently the initialization is an issue. I'll assume there's a bug in my code or some way around that, so generics could work. I just wanted to know
<FromGitter>
... if there were a way besides generics to solve this problem, since generics seem like a more powerful tool than this case seems like it requires. Maybe that's a silly sense that I have, but still.
tankf33der has joined #crystal-lang
<FromGitter>
<kinxer> Also, thanks for the link to the description of the XY Problem. That's valuable information.
Renich has quit [Remote host closed the connection]
Renich has joined #crystal-lang
Renich_ has joined #crystal-lang
Renich has quit [Ping timeout: 246 seconds]
Renich_ is now known as Renich
Dreamer3_ has quit [Quit: Computer has gone to sleep.]