<FromGitter>
<watzon> Support in the Crystal compiler itself
<rkeene>
I don't know, probably just poor support for it within Crystal... but generally totally static executables aren't a great idea (and most OSes don't support them anyway)
<FromGitter>
<watzon> I did just run `crystal build` with the `--static` and `--cross-compile` flags together though and didn't get any errors
<FromGitter>
<watzon> Yeah that's true
<FromGitter>
<watzon> Sucks
<FromGitter>
<watzon> Ahh I got an error when trying to link the `.o` file though
<rkeene>
You probably just want to link statically to a few things which you would otherwise redistribute
<rkeene>
You'll need to specify all the libraries when linking
<rkeene>
ELF shared objects indicate what other libraries they require, but relocatable objects (.o files) don't do this so you have to know
<rkeene>
(this is also why you have to include all transitive dependencies when linking statically -- .a (Archive) files are just a group of ELF relocable object files, basically like a zip file without the compression)
<rkeene>
As far as I can tell --static within Crystal doesn't care about what platform it is on
rohitpaulk has quit [Remote host closed the connection]
alex`` has quit [Ping timeout: 272 seconds]
alex`` has joined #crystal-lang
lucasb has joined #crystal-lang
<FromGitter>
<Blacksmoke16> prob so you can just do `require "arachnid"`
duane has joined #crystal-lang
<FromGitter>
<cfsamson> Does anyone know if how (or if) it's possible to access `GC.stack_bottom`. I see this code in `src\crystal\shceduler` and I'm trying to extract out the part of Fibers that does the context switch but it seems the GC is giving me trouble when resuming from a stack, and there is this in the source code: ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ But I get `undefined method 'stack_bottom=' for GC:Module` if I
<FromGitter>
<kinxer> Regarding the `<project_directory>/src/<shard_name>` pattern, I think it's a useful convention for separating library code from driver/setup code. Even when you don't have a driver or setup to do, I think it's useful to use the convention so people know where things are. It also makes it so that you can have another directory under `src/` if you need another, separate `module`.
<FromGitter>
<Blacksmoke16> the issue is that json doesnt allow non string keys
<FromGitter>
<Blacksmoke16> so when trying to deserialize the json string into an object, it doesnt work since the hash needs Int32 keys, while the json is using String keys
<FromGitter>
<girng> he's sending an int32 to the constructor tho
<FromGitter>
<girng> it works
<FromGitter>
<watzon> Also, "```crystal"
<FromGitter>
<watzon> Just sayin
<FromGitter>
<Blacksmoke16> right, but he wants the keys of his hash to be `Int32` not strings
snsei__ has joined #crystal-lang
<FromGitter>
<girng> if he needs the keys to be int32 he can just do `pp y.locations.keys.map &.to_i`
<FromGitter>
<Blacksmoke16> but again thats not the issue
<FromGitter>
<Blacksmoke16> doing from_json on his obj should convert the keys from the JSON string to Int32 keys
<FromGitter>
<Blacksmoke16> also `y.locations.transform_keys &.to_i` would be better
<FromGitter>
<girng> yeah was just reading bcardiff's post, i don't think json spec allows keys to be ints, so it might not even be an issue
<FromGitter>
<Blacksmoke16> it doesnt
<FromGitter>
<Blacksmoke16> thats the whole point of the issue :P
<FromGitter>
<girng> isn't crystal conforming to json spec's standards?
<FromGitter>
<Blacksmoke16> when generating the json yes, but it should handle the conversion from valid json, into the types you want
<FromGitter>
<Blacksmoke16> in this case at least
<FromGitter>
<girng> but the types he wants, doesn't follow json's spec
<FromGitter>
<Blacksmoke16> it doesnt matter at that point because hes not using json
<FromGitter>
<Blacksmoke16> he wants `{"0": "foo"}` in JSON to be deserialized to a crystal hash like `{0 => "foo"}`
<FromGitter>
<Blacksmoke16> because he typed his hash to be `Hash(Int32, String)`
<FromGitter>
<Blacksmoke16> i.e. just convert `"0"` to a number on deserialization, based on the type of `K` in the hash. like `asterite ` mentioned
rohitpaulk has quit [Remote host closed the connection]
<FromGitter>
<watzon> Ok, using the `future` approach I just created a sitemap of forum.crystal-lang.org in like 3 seconds. I better be careful or I'm going to end up with an accidental DOS attack 😂
<FromGitter>
<watzon> This is the sitemap that was generated in 3 seconds
<FromGitter>
<Blacksmoke16> hes trying to deserialize `{"locations":{"2":"Alfa"}}` which is valid
<FromGitter>
<watzon> With great power comes great responsibility
<FromGitter>
<Blacksmoke16> to_json is basically doing like `hash["2"] = "Alfa"` but since his hash is typed to `Hash(Int32, String)` it doesnt compile
<FromGitter>
<girng> `property locations = {} of Int32 => String`
<FromGitter>
<girng> doesn't map to valid json
<FromGitter>
<Blacksmoke16> it generates valid json, but cant consume said json
<FromGitter>
<Blacksmoke16> which is the issue
<FromGitter>
<Blacksmoke16> because crystal is always assuming the key is going to be a string
<FromGitter>
<Blacksmoke16> when deserializing the json
<FromGitter>
<watzon> Here's what I came up with for my queue
<FromGitter>
<Blacksmoke16> it *generates* valid json
<FromGitter>
<girng> why
<FromGitter>
<girng> it should error?
<FromGitter>
<Blacksmoke16> no
<FromGitter>
<girng> that literally makes zero sense
<FromGitter>
<Blacksmoke16> because its not a `1:1` mapping
<FromGitter>
<girng> so we can have int : value hashes that generate valid json by converting the int32's to a string. but when loading invalid json, it doesn't convert to a string, but errors out
<FromGitter>
<Blacksmoke16> there is some code that takes crystal objects (in this case a hash), and encodes the data into a valid JSON string
<FromGitter>
<Blacksmoke16> its loading valid JSON
<FromGitter>
<girng> if a hash is an int : value, it should not be allowed to export to valid json, because json spec says keys are strings
<FromGitter>
<girng> like wtf
<FromGitter>
<Blacksmoke16> but the deserialization step isnt taking into consideration there can be other types of keys besides String
<FromGitter>
<watzon> You can generate JSON from anything that implements to_json
<FromGitter>
<watzon> But `from_json` requires valid json to parse
<FromGitter>
<Blacksmoke16> it's `to_json`'s responsibility to generate valid json
<FromGitter>
<girng> well that just will confuse the developer
<FromGitter>
<girng> because now they can't load it again
<FromGitter>
<girng> because it's not valid json
<FromGitter>
<Blacksmoke16> which knows, `hey this key is an Int32, JSON only allows String. I'll convert it to String`
<FromGitter>
<Blacksmoke16> *its valid json*
<FromGitter>
<Blacksmoke16> how many times to have to say that :P
<FromGitter>
<girng> `property locations = {} of Int32 => String`
<FromGitter>
<girng> how many times
<FromGitter>
<girng> do i need to paste that
<rkeene>
I don't even know why you guys think your disagreeing with each other
<rkeene>
your -> you're
<FromGitter>
<girng> `property locations = {} of Int32 => String` is assuming the INCOMING JSON DATA will be: `%({"locations":{2:"Alfa"}})`
<FromGitter>
<girng> ..which is *not valid json*
<FromGitter>
<Blacksmoke16> but thats not the problem
<rkeene>
Right, so the core disagreement is that since the JSON deserializer knows it can't actually look like that it should look for the only possible interpretation of that, "2" must start out as a string and be converted into an Int32, or fail
<FromGitter>
<Blacksmoke16> `the deserialization step isnt taking into consideration there can be other types of keys besides String`
<FromGitter>
<Blacksmoke16> right
<FromGitter>
<Blacksmoke16> then based on the type of `K` in your hash, convert it to the expected type
<rkeene>
Well, it knows that the JSON side will always be a string but the desired internal representation could be something different, and apply the correct schema or fail to decode
<FromGitter>
<girng> but the deserailization should conform to json's spec, where keys are *strings* only
<FromGitter>
<Blacksmoke16> deserialization isnt part of the JSON spec, its the act of converting one format into another
<rkeene>
girng, That's the JSON representation, when deserializing it can apply a schema
<FromGitter>
<Blacksmoke16> JSON just happens to be the input
<FromGitter>
<Blacksmoke16> in this case we're converting JSON into an object, which can have logic that can do this
<rkeene>
Bloacksmoke16, JSON is just one representation, and a lossy interchange format -- since we know it's lossy and the ways in which it is lossy it's possible to unambigiously do the right thing (or fail)
<FromGitter>
<girng> @Blacksmoke16 yeah, but were also applying logic to that object, to make it conform to spec
<FromGitter>
<girng> if a hash is not string key based, how can it conform to the spec??
<FromGitter>
<girng> by cheating?
<rkeene>
The basic cause of this is that the schema doesn't exist within JSON, it's external so it has to be managed externally
<FromGitter>
<girng> then, now, we get issues like that one where it confuses the developer
<FromGitter>
<girng> because they think the int32 will work
<rkeene>
girng, The representation within the JSON output is a string, when converting it to a different representation you can unambigiously convert it to a known schema (or fail) *IF* a schema is given
<FromGitter>
<Blacksmoke16> its not cheating tho. its taking a known format with a known structure, and applying logic to it to get the desired output
<FromGitter>
<girng> this is why it's important to conform to the spec on serializing and deserializing
<rkeene>
This is just applying a schema to decoding JSON, it's well understood, well documented, and not confusing.
<FromGitter>
<Blacksmoke16> which in this case is an object
snsei__ has quit [Remote host closed the connection]
<jokke>
ooh that is awesome!
<sorcus>
crystal_lib doesn't want generate binding for macro function `lxb_dom_interface_document`. This is what i got - `Unhandled exception: can't find function lxb_dom_interface_document (Exception)`
<jokke>
how does it handle callbacks?
<jokke>
sorcus: of course not
<jokke>
it's not a function
<jokke>
it's a macro
<sorcus>
Yeah, i understand it.
<jokke>
it won't create bindings for constants defined with #define either
<jokke>
or does it?
<jokke>
i don't think it does. but it would be amazing if it did
<FromGitter>
<watzon> One of the many issues I have with the current doc generation
<FromGitter>
<mwlang> meh. I'm struggling with it as well.
<FromGitter>
<mwlang> is documentation on the table generally speaking to be improved or is it more or less what we have is what we get for foreseeable future?
<FromGitter>
<wontruefree> is that a problem with the markdown parser in the stdlib?
<FromGitter>
<mwlang> (heh, no pun was intended with that use of "on the table"...)
<jokke>
:D
<jokke>
wontruefree: it's just very basic, that's all;
<FromGitter>
<watzon> Hopefully doc generation will get better
<FromGitter>
<watzon> Or we will have a choice of multiple generators in the future
<FromGitter>
<watzon> Like with ruby's YARD and rdoc
<FromGitter>
<wontruefree> I would prefer crystal choose a format and if other people want to make other tools that is awesome
<FromGitter>
<wontruefree> I have a love hate relationship with markdown
<FromGitter>
<watzon> Same. What I want is templates
<FromGitter>
<watzon> And metadata tags in comments
<FromGitter>
<watzon> Like `@see` and `@note`
<FromGitter>
<mwlang> yeah, I've been wanting that as well.
<FromGitter>
<wontruefree> I am curious if you would make a document format out of code and macros
<FromGitter>
<mwlang> I know backticks kind of sort of work...as long as you're in the same namespace
<FromGitter>
<mwlang> gets cumbersome to type it all out all the time.
<FromGitter>
<wontruefree> yeah and it seems like there are bigger fish to fry
<FromGitter>
<watzon> @wontruefree what do you mean?
snsei__ has joined #crystal-lang
<jokke>
probably parallelilsm and windows support :P
<jokke>
-l
<FromGitter>
<mwlang> another would-be-nice-to-have is to write annotated specs that builds browseable documentation.
<FromGitter>
<mwlang> As it is, it just looks terrible:
<FromGitter>
<watzon> Yeah
sz0 has joined #crystal-lang
<FromGitter>
<wontruefree> @watzon there are other features like windows support or something that probably take priority
sorcus has quit [Quit: WeeChat 2.5]
<FromGitter>
<jwoertink> I have a macro where I call `run`, but I keep getting a "can't find file" error. Is there a way to see what file context I'm in at the point it runs?
<FromGitter>
<watzon> Yup there are. Really the standard library needs to be divided up first, and ideally the documentation generator needs to be separated from the compiler into it's own shard.
<FromGitter>
<tenebrousedge> so your expression is just pulling off the parens
<FromGitter>
<watzon> Of course `Time.now.to_s("\\1") #=> "\\1"` is going to output `"\\1"` if you don't have a regex match group to pull from
<FromGitter>
<tenebrousedge> no, that's going to execute before `gsub` does
<FromGitter>
<watzon> Ok that makes sense
<FromGitter>
<watzon> But then why do I still get `"hello-%F"` as the output?
<FromGitter>
<tenebrousedge> because it's subbing out the entire match
<FromGitter>
<tenebrousedge> maybe use `\K`
<FromGitter>
<tenebrousedge> I think you need an explicit block too
<FromGitter>
<tenebrousedge> something like `string.gsub(/time\(\K[^)]+/) { |m| Time.now(m) }`
<FromGitter>
<tenebrousedge> with whatever `to_s` or matchdata manipulation you need in the block
<FromGitter>
<cfsamson> May I ask why you want to do this with a regex and not just `sub("%F")`?
<FromGitter>
<tenebrousedge> that is a good question o__o
<FromGitter>
<watzon> Good point. More than anything I was just wondering why it wasn't working
<FromGitter>
<cfsamson> Ok :)
<FromGitter>
<watzon> I also don't just want `%F`
<FromGitter>
<watzon> I want to be able to include any of the valid `Time::Format` options
<FromGitter>
<watzon> I'm trying to make a command line formatter for an image downloader
<FromGitter>
<tenebrousedge> I think my next project is `scanf`
<FromGitter>
<cfsamson> Ah, ok, I see.
<FromGitter>
<watzon> `scanf` would be awesome to have in the stdlib
<FromGitter>
<tenebrousedge> I'm probably going to follow Ruby in returning the resulting array rather than following C and returning an integer
<FromGitter>
<watzon> That's what I'd do
<FromGitter>
<watzon> Writing results to a buffer is a very outdated way of doing things
<FromGitter>
<tenebrousedge> outdated to the point where it's preferable to rewrite the method in Crystal even though it's technically possible to just use the C version
snsei__ has joined #crystal-lang
<FromGitter>
<mwlang> Does Crystal have it's own version of Timecop or Delorean for freezing/advancing Time.now in specs?
<FromGitter>
<mwlang> basically, API signed calls are time sensitive, so I have to capture/freeze the time when recording a new playback and then set the time to that same time when playing it back.
<FromGitter>
<mwlang> I just realized, I hadn't committed the latest.
<FromGitter>
<mwlang> using begin/ensure in latest to guarantee unfreezing.
sz0 has quit [Quit: Connection closed for inactivity]
<FromGitter>
<watzon> Change `def with_vcr_cassette(name : String)` to `def with_vcr_cassette(name : String, &block)` and then replace `yield` with `block.call`
<FromGitter>
<watzon> That should work
<FromGitter>
<watzon> You might have to do `def with_vcr_cassette(name : String, &block : Nil ->)`
<FromGitter>
<watzon> Image downloading with `imgd` works like a charm
asterite has joined #crystal-lang
<FromGitter>
<bararchy> @watzon looks awsome
<FromGitter>
<watzon> Thanks :) I need to implement an option that's the opposite of ignore though
<FromGitter>
<bararchy> whitelist v.s blacklist ?
<FromGitter>
<mwlang> @watzon thanks for that tip. I'll give it a shot. I figured it had to do with not explicitly naming a block argument, but I didn't know how to define it's return type since I really didn't want it to matter.
<FromGitter>
<watzon> Hmm weird that the underscore doesn't work. It's possible it only works as a generic return type
<FromGitter>
<mwlang> possible. It's definitely a topic I hope to dig further into at some point. For now, really focusing on pushing through getting all the API endpoints coded and passing
<FromGitter>
<mwlang> then I'll circle back around and try to understand some of crystal's finer implementation points like this one.
snsei__ has quit [Ping timeout: 276 seconds]
bougyman has quit [Ping timeout: 246 seconds]
bougyman has joined #crystal-lang
<FromGitter>
<mwlang> seeing this a lot today: mwlang/.cache/crystal/crystal-run-spec.tmp): No such file or directory: No such file or directory (Errno)
<FromGitter>
<mwlang> running specs
<FromGitter>
<mwlang> rerunning specs immediately usually resolves it.
<FromGitter>
<mwlang> oh, and running specs automatically with guardian.
<FromGitter>
<mwlang> so I should clarify, "saving again with no changes" causes guardian to retry w/no errors.