<FromGitter>
<jwaldrip> Hey, anyone available to help with some YAML PR I am working on. I am trying to find out how the `YAML::PullParser` translates into calling the right args on `LibYAML.yaml_scalar_event_initialize`.
<FromGitter>
<johnjansen> on a similar note, anyone like to give me a hint about how to best serialize something like a logger or an http server instance i.e. i want to hijack YAML.mapping and use it for config, instantiating a Logger or HTTP::Server when the config for the app is loaded … i know there are other solutions, im just pondering this one
<FromGitter>
<sdogruyol> Morning everyone
<FromGitter>
<johnjansen> morning @sdogruyol
<FromGitter>
<johnjansen> i think that i might be “everyone” at the moment
<FromGitter>
<sdogruyol> Hey @johnjansen how are you
<FromGitter>
<johnjansen> great … reverse proxy worked almost immediately … now just reorganizing and getting it all configurable etc
<FromGitter>
<johnjansen> weighing up my options
<FromGitter>
<sdogruyol> wow, amazing
<FromGitter>
<sdogruyol> wild guess but you're getting virtual hosts from config?
<FromGitter>
<johnjansen> yeah ive been looking at that, going in circles a little, wanting to hijack a mapping to turn the following YAML ⏎ ⏎ ```logger: ⏎ level: WARN ⏎ directory: logs``` ⏎ ⏎ into a `Logger` instance … [https://gitter.im/crystal-lang/crystal?at=5996770f76a757f808b81a24]
rohitpaulk has quit [Ping timeout: 240 seconds]
<FromGitter>
<bararchy> It's great to see Ary active again :)
<FromGitter>
<crisward> I've got a Room class I'm using with websockets. On this class I have a method which sends a payload to everyone in the room. However I'm getting a `Closed stream (IO::Error)` So I'm guessing my check for a closed socket is incorrect. ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=59969886578b44a046c05e31]
<FromGitter>
<crisward> Any ideas?
snsei has quit [Remote host closed the connection]
<FromGitter>
<crisward> Should I just be wrapping it in a begin / rescue instead ?
<FromGitter>
<crisward> do I need to assign socket.closed? to a local variable first?
<FromGitter>
<sdogruyol> @crisward you better remove the socket on the
<FromGitter>
<sdogruyol> on_close event
<FromGitter>
<sdogruyol> I think there's no way to check if a socket is closed other than the event
<FromGitter>
<bew> The process about knowing if a socket is closed or not involve a read or write operation. You can't know if it's closed without reading from or writing to it. `Socket#closed?` is only useful when it has already been closed, and you want to check if it's already closed or not, so it won't mess up. But keep in mind that it needs to fail once before you know it's closed..
<FromGitter>
<sdogruyol> that sound a bit unintuitive
<FromGitter>
<sdogruyol> hmm that's unexpected then
<FromGitter>
<sdogruyol> how about using a begin .. rescue in your broadcast
<FromGitter>
<crisward> the above remove method, pops it off the array of sockets I'm storing. Perhaps there are times when on_close is not fired?
<FromGitter>
<bew> Yeah but it's how sockets works
<FromGitter>
<sdogruyol> yes there are
<FromGitter>
<sdogruyol> for example when the connection is gone in the middle e.g
<FromGitter>
<sdogruyol> that
<FromGitter>
<sdogruyol> that's why there are some ping / pong / heartbeat mechanisms to check if a socket is alive
<FromGitter>
<crisward> I think I'll add a begin rescue. Do you think I should remove the socket from the array in the rescue, or can it recover without reconnecting?
<FromGitter>
<sdogruyol> I don
<FromGitter>
<sdogruyol> ughh i hate this new keyboard, sorry
<FromGitter>
<sdogruyol> i dont think it can recover
<FromGitter>
<crisward> OK, I'll remove it. Thanks.
<FromGitter>
<sdogruyol> It's better to be a bit defensive 😄
<FromGitter>
<sdogruyol> why not just remove socket in rescue
<FromGitter>
<crisward> I'm worried another error type may remove the socket. Not sure what that could be, but I'm presuming socket.closed? will return true if the state has changed since I tried to send the message.
<FromGitter>
<sdogruyol> I'm unsure of socket.closed? but it
<FromGitter>
<sdogruyol> but it's your call 💃
<FromGitter>
<crisward> I'll give the above a go, if it doesn't fix the error, I'll remove the if block. BTW this is only happening on our live site, can't recreate the issue locally. We have lots of people go to the site on mobile. Android seems to keep sockets open when in standby, and these are kept open for hours.
<FromGitter>
<sdogruyol> @jose-rodrigues it's because you are not assigning a new variable 👍
<FromGitter>
<sdogruyol> so there's no inference going on
<FromGitter>
<bew> what's the easiest way to pass a function pointer to a binding, without the context data? (the function is defined as `fun function; ...; end`)
<FromGitter>
<sdogruyol> hey @RX14 nice way to start a day with a merge 💯
<crystal-gh>
[crystal] ysbaddaden closed pull request #4698: Format: raise an error if unclosed paren is found on finish (master...fix/crystal-format/error-if-paren-count-1-more) https://git.io/vQPc4
<crystal-gh>
[crystal] ysbaddaden closed pull request #4747: Display type when inspecting numbers (master...feature/show-int-type) https://git.io/v7Ytz
<crystal-gh>
[crystal] ysbaddaden pushed 1 new commit to master: https://git.io/v7hH5
<crystal-gh>
crystal/master a0f31a5 Oleh Prypin: Remove '$0' special syntax
<crystal-gh>
[crystal] ysbaddaden closed pull request #4846: Remove dead line of code (master...pointer-useless-loc) https://git.io/v7hGt
<Groogy>
though it still has to be same kind of code as if you weren't using a macro, so if you want the method to be available to call you have to do def self.method_name
<office_boy>
Also, is there a way to give a macro parameter a default value, the way you would do: def method(param="default"), for example
hightower2 has joined #crystal-lang
<FromGitter>
<bew> as in `macro hey(param = "default")` ?
<office_boy>
Yes, can you do that?
<FromGitter>
<bew> did you tried?
<office_boy>
Good question, should have probably tried. Just did and it works :P soz
<FromGitter>
<bew> @faustinoaq you can always use your own prelude file, and redefine `main`
<FromGitter>
<bew> about `GC.disable` it's just the garbage collector that doesn't run iirc, so it'll fill up the memory, but you still don't have control on it I think
<FromGitter>
<bew> @faustinoaq you'll enter the 4th dimension probably 😆
<FromGitter>
<bew> What would happen? I think that any allocation will fail/raise/crash
office_boy has quit []
<FromGitter>
<faustinoaq> 😆 So Still would be possible to use Stack memory? I mean `StaticArray`, `fun`, `struct`etc
<FromGitter>
<bew> I you don't try to allocate anything, yes
<jokke>
barachy: i thought of hacking something together using newlib nano
<Papierkorb>
faustinoaq, you can use all memory, including heap, you just have to use a memory allocator manually (LibC.malloc is fine). The part where it comes crashing down is that almost everything in the stdlib will gladly allocate memory (which you can override, no biggie), but will rely on the GC (which you don't have) to release that memory later on. And that's the part where writing code becomes un-fun, Crystal was created with the assumption
<Papierkorb>
of automatic memory management.
<Papierkorb>
Sorry, wrong window
<FromGitter>
<bew> ?
<Papierkorb>
Even with wrong focus *inside* the irc window. Great. Nevermind >_>
<RX14>
and no, we can't possibly force the installation of clang everywhere we need to link
<RX14>
why would we go so far as only supporting clang when we don't even know the problem yet
<RX14>
we only know of 1 workaround: use clang
<RX14>
which is a hint at the problem
<vegai>
I guess a better way to do this would be to understand why gcc doesn't work, yes ;)
<RX14>
exactly
<Papierkorb>
Is your gcc installation outdated?
<RX14>
an even better way would be to use a linker directly
<RX14>
not sure of the downsides to that though
<vegai>
Papierkorb: I don't think so, this is Debian sid
<RX14>
it might not be better
<vegai>
gcc-7.1.0
<Papierkorb>
Which would most likely introduce funny problems with linking to c libs one never even heard of RX14
<RX14>
why?
<RX14>
we don't pass c files to the lniker
<Papierkorb>
Wouldn't surprise me, really
<vegai>
14:54 < RX14> and no, we can't possibly force the installation of clang everywhere we need to link
<RX14>
cc mostly passes the args through
<vegai>
we can force the installation of gcc, then? :)
<RX14>
no
<RX14>
we require *a* cc
<RX14>
not gcc
<vegai>
indeed
<RX14>
not clang
<RX14>
a cc
<vegai>
I could try to dig into this if I had a clue what to do
<RX14>
i'm sure noones tried it but tcc might even work
<Papierkorb>
Though `gcc` is a fair guess on a linux system for the most part
<RX14>
^
<vegai>
well, Debian doesn't have it, neither does Arch
<vegai>
in the base install, that is
<Papierkorb>
Developers don't have the bare-minimum base install
<Papierkorb>
Heck, it's part of the "base development" package group, whatever it's called
<vegai>
yes, there it is on both distros
<vegai>
build-essential on debian, base-devel on Arch :)
<Papierkorb>
Which is what developers have, because they need it to do anything at all
<vegai>
that is true
<Papierkorb>
I mean you even need libgc on top of that
<vegai>
one stackoverflow article mentioned a possibility that library dependencies could be in the wrong order, which might cause a linking by gcc to fail
<Papierkorb>
yup
<vegai>
can I make the process more verbose somehow, so I could see all the things that get called
<vegai>
"make crystal" that is
<RX14>
copy the compiler command from make crystal
<RX14>
add -v
<RX14>
it prints the cc command
<RX14>
you might want to try --single-module
<RX14>
or actually just stick --cross-compile on
<RX14>
that's the easiest way to get the lniker command
<RX14>
it's not exactly the way the linker is used without --cross-compile
<RX14>
but if it reproduces then it's enough
<vegai>
umm...
<linuksz>
how can i read a character from stdin?
<Papierkorb>
linuksz: unicode character, or single byte?
<linuksz>
unicode char
<Papierkorb>
IO#read_char
<vegai>
RX14: is it interesting that the build succeeds with --cross-compile?
<RX14>
yes
<RX14>
but perhaps not surprising
<linuksz>
Papierkorb: and which io should i invoke the read_char method?
<Papierkorb>
linuksz: STDIN
<linuksz>
so STDIN.read_char ?
<Papierkorb>
yes.
<linuksz>
thanks.
<vegai>
RX14: --verbose reveals that -lffi is not on the command line in the call to cc
<vegai>
neither in the call to clang, though
<RX14>
well why would it be
<RX14>
and what requires it
<vegai>
dunno, the original error message contains this
<vegai>
//usr/lib/x86_64-linux-gnu/libffi.so.6: error adding symbols: DSO missing from command line
<vegai>
hence me making blind observations
<RX14>
soo
<vegai>
yeah...
<RX14>
libffi is getting in there
<RX14>
most likely from the llvm-config invocation
<Papierkorb>
bitmappergit, have a look at `#loop`, `Int#downto`, possibly `pp` and also `Enumerable#map`.
<Papierkorb>
bitmappergit, it's unecessary to explicitly write the type of an array literal that is not empty, like on line 25
<FromGitter>
<bitmappergit> i know
<FromGitter>
<bitmappergit> originally it was empty
<FromGitter>
<bitmappergit> well not that one
<FromGitter>
<bitmappergit> but 1 and 2 were
snsei has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
<FromGitter>
<bitmappergit> how do i set a variable's type
<Papierkorb>
The notation is in general: `NAME : TYPE = VALUE`, while the `: TYPE` part mostly optional is
<Papierkorb>
Though you only really need that for class and instance variables, method arguments if you want (rarely: need), block arguments. It's highly unusual to type local variable in that way.
<FromGitter>
<bitmappergit> no it's just i was getting a buffer overflow i think
<FromGitter>
<bitmappergit> couldn't tell cause output was getting cut off
<crystal-gh>
[crystal] RX14 closed pull request #4614: On macro run error: show status, stdout and stderr (master...show-errors-for-macro-run) https://git.io/vQmAJ
sz0 has quit [Quit: Connection closed for inactivity]
relaxbox has joined #crystal-lang
<FromGitter>
<LuckyChicken91_twitter> why is there no description to `downto` in devdocs
<Groogy>
oprypin I don't work at CD Project Red :P I didn't mean all games, I meant specifically the ones I've worked on
<oprypin>
k
<imusingnotepad>
im finding it cool that its still possible to program 8bit games or something
<watzon>
32 bits goes all the way to 4,294,967,295
<watzon>
and 64 to 18,446,744,073,709,552,000
<Groogy>
huh can you tell the compiler to only do 8bit pointers?
<watzon>
I also find this kinda cool, but I also started with JavaScript and then moved on to bigger and better things
<oprypin>
Groogy, uh wut no?
<Groogy>
no was refering to imusingnotepad and didn't think that is possible
<oprypin>
memory addresses almost never use low integers because they're reserved
<Groogy>
I mean you can choose to write all the integers in 8bit and so on but you will still have a larger memory address range than in 8bit systems
imusingnotepad has quit [Quit: Page closed]
<watzon>
Looks like imusingnotepad is done with us
<Groogy>
aw :(
<watzon>
I wish Crystal was stable already. I'm starting a rather large project for a client and I would love nothing more than to use it
<FromGitter>
<mgarciaisaia> Yeah, I'm not *that* sure that's an issue
<Papierkorb>
ah man, I missed all the fun
<watzon>
Yeah you did
<watzon>
86 bits of fun
<Groogy>
did I miss something?
<FromGitter>
<mgarciaisaia> Given that: 1) you're not forced to upgrade to the latest Crystal; 2) breaking changes arent *that* big; and 3) the compiler *really* helps you notice what's to be fixed
<Groogy>
for me I just want full-fledged windows support :(
<watzon>
Unfortunately it is an issue with the client though. I'd normally just use it anyway, but he doesn't want me to
<watzon>
So alas, JavaScript it is :'(
<FromGitter>
<mgarciaisaia> It's not 1.0-stable yet, but calling it "alpha stage" is just us being *really* conservative
<watzon>
How fad do you think we are from 1.0? I know there's still quite a bit to do
<watzon>
far*
<Groogy>
mgarciaisaia do you work on it?
<Groogy>
also do someone know how the linkage happens with shared libraries?
<Papierkorb>
watzon: "quite a bit to do" sounds like the most reasonable estimate to give
<Groogy>
I am trying to figure out how it manages to link correctly with OpenGL when it shouldn't
<Groogy>
are methods resolved on first usage?
<Groogy>
or on launch?
<Papierkorb>
At compile time
<Papierkorb>
and likely virtuals at run-time for overloading, no idea
<watzon>
mgarciaisaia: you work for humanas, right?
<oprypin>
Papierkorb, there's actually little happening at compile time
<Groogy>
Yeah thought so
<oprypin>
at least at runtime it needs to find the library file and look up the function in the symbol table
<FromGitter>
<mgarciaisaia> *Humanas* sounds a great name :)
<FromGitter>
<mgarciaisaia> I work at Manas, yeap
<Groogy>
only way I can explain why the symbols don't need to be reloaded is because it is resolved after I create the OpengL 4.5 context
<oprypin>
but there's at least something happening at compile time
<watzon>
I knew I got it wrong lol
<Papierkorb>
oprypin: that's what the loader does, nothing much Crystal does
<watzon>
Manas*
<FromGitter>
<mgarciaisaia> I'm the one to blame for the issues with 0.23.0 ^_^
<watzon>
If you guys ever want to hire a gringo my wife and I would love to come down to Argentina ;)
<watzon>
Lol
alex`` has quit [Quit: WeeChat 1.9]
<FromGitter>
<mgarciaisaia> More than happy to host you if you want to come :)
<FromGitter>
<mgarciaisaia> As for the job, we're currently looking for devs, so shoot a CV at hello@manas.tech :)
<watzon>
Her spanish is much better than mine. I speak better Portuguese :D
<FromGitter>
<mgarciaisaia> Don't think our ugly pesos will make a gringo happy, but you can try :)
<watzon>
Hahahaha
w-p has quit [Ping timeout: 240 seconds]
<Groogy>
for curiousity I checked for a career page on manas.tech but alas nothing :P
<Groogy>
do love the actual coffee meter on the site
<watzon>
I've checked for that as well
<FromGitter>
<mgarciaisaia> 😹 It's *really* hidden in our Staff page... which is hidden already
<Groogy>
ah lol the "put your picture here" button?
<FromGitter>
<mgarciaisaia> :)
<oprypin>
but that's still just a contact email
<FromGitter>
<mgarciaisaia> We did a nice looking site, but there are a couple of basic things we haven't added yet `¯\_(ツ)_/¯`
<watzon>
Pretty sure I wouldn't have a hard time convincing my wife to move
<FromGitter>
<bew> oprypin yeah me too, no way to share specific information..
<FromGitter>
<mgarciaisaia> LLVM required upgrading `gcc` version, which in Centos could be done via the `devtoolset`s things they have. I've used the newer gcc 4.8-something to build LLVM, and then succeeded compiling Crystal in that same Centos but with the stock, older gcc 4.3
<oprypin>
mgarciaisaia, i have nothing helpful to say but i'm not surprised by this. so is there any good reason to not use LLVM compiled for the same OS you're using it on?
<FromGitter>
<bew> wow gcc is old there, I have v7.1.1
<FromGitter>
<mgarciaisaia> I think the idea is that it's only arch-dependent, so it shouldn't matter which distro you've compiled in - that's how we have been doing this since I'm aware of the process
<FromGitter>
<mgarciaisaia> Besides that, Debian has a gcc 4.4 I think, so it can't build LLVM 4.0.1 - and if I upgraded gcc for building Crystal, it would depend on a newer libstdc, so it won't work on stock Debian 7's (like what happened with 0.23.0)
<oprypin>
why is g++ involved here, again?
<FromGitter>
<bew> I think he meant libc, not libstdc
<oprypin>
this looks like trying to compile (at least a part of) LLVM with GCC
<FromGitter>
<mgarciaisaia> @oprypin that's a good question - the failing command is a `g++` one
<FromGitter>
<mgarciaisaia> It's trying to compile `src/llvm/ext/llvm_ext.o`
<Papierkorb>
Groogy: Didn't ask as I scratched the idea. Figured that besides Manas I'd also need to contact Digia for Qt. Doesn't sound worth the hassle for now.
<oprypin>
Papierkorb, you know what is worth the hassle?
<Papierkorb>
Telling you what new stuff works today?
<Papierkorb>
C++ template instantiation for sequential containers, aka, std::vector, QList, QVector
<oprypin>
Papierkorb, no you know what i want
<Groogy>
what interesting things are you talking about Papierkorb?
<Groogy>
C/C++ wrapper or something for Crystal?
<Papierkorb>
on a more serious note, it's not far off for a public preview. However, tomorrow I won't have much time, neither sunday. Still have to post-process some photos I took (models are waiting). Maybe Monday or Tuesday
<Papierkorb>
Groogy: Qt bindings for Crystal, the generator could (and will?) be taught some more tricks for more general C/C++ libs though
<oprypin>
Papierkorb, yeah just make it complicated enough so i dont understand it, and wait until i dont have time
chova has quit [Ping timeout: 260 seconds]
<oprypin>
mgarciaisaia, I think it's just code that does not support this compiler anymore, simply enough
<oprypin>
i'm curious why this llvm_ext is not shipped across platforms the same way, the same claims should apply to it
<FromGitter>
<bew> when I do `my_array += [1, 2]` will it create a new array? or will it add the second to the first one?
<oprypin>
bew, create a new array
<FromGitter>
<bew> hmm ok, 'll use #concat then, thanks
<FromGitter>
<johnjansen> on that topic … wouldnt any change create a new array and replace the old one?
<oprypin>
no
<FromGitter>
<johnjansen> k
<FromGitter>
<johnjansen> good to know
<oprypin>
well there are some technical details
<oprypin>
of course the underlying buffer could get recreated at any time
<FromGitter>
<mgarciaisaia> LLVM was compiled in Centos with gcc4.8.2. I *could* compile Crystal in Centos with gcc 4.4.7, but fails on Debian with gcc 4.7.2
<FromGitter>
<johnjansen> thats more what i was thinking … i probably worded it badly
<FromGitter>
<mgarciaisaia> So it's a version in the middle the one that's failing
<FromGitter>
<mgarciaisaia> Those are (trying to get) compiled with gcc 4.4.7 (works) and 4.7.2 (fails)
<oprypin>
johnjansen but it doesnt have to be every change, u can have an array of size 9 capacity 16 and add 5 items to it - no recreation
<oprypin>
oh huh, then I'm probably wrong
<FromGitter>
<mgarciaisaia> *Oh* I'm lying to you! I think the build process uses the newer GCC for Crystal itself, too. So *that* makes sense. I'll try that.
<oprypin>
mgarciaisaia, but in any case, doesn't it make more sense to build llvm_ext on the same system that llvm is built on
<FromGitter>
<bew> note: lying is conscious I think, if you didn't know you were wrong, you weren't lying
<FromGitter>
<mgarciaisaia> @oprypin mmm... I'm don't know *that much* about that. For a starter, that llvm_ext is on Crystal's repo, not even in omnibus-crystal. So, it may be a totally abitrary decision, but I should check first if there's any good reason why that's compiled with the compiler itself instead of LLVM
<FromGitter>
<mgarciaisaia> I'm trying to build on Centos with gcc 4.7.2 (the same that Debian uses). If this fails, it's because of the compiler, yeap
<oprypin>
no if this fails then that doesnt explain anything
<oprypin>
if you compile almost the same codebase with the same compiler it shouldn't fail on a different system
<FromGitter>
<mgarciaisaia> 🎉 It failed with gcc 4.7.2 in Centos - so the issue is gcc compat
<FromGitter>
<mgarciaisaia> Don't have a single clue regarding *how* to bypass that, but at least it's consistent
<Papierkorb>
oprypin: I can't know your time constraints. In terms of complexity, this project is a complexity monster by its very definition. I already have some rules in place (documented, even) to "combat" it. Though these docs are something I push beyond the initial TP release. Quality is king. I can't write good docs right off the bat, so that's postponed. Feature-wise, there's a bug in the subclassing stuff. After the current feature, and that,
<Papierkorb>
I'll add a bunch of classes to the configuration (Though with each new class, things get easier, as the generation simply got more robust). And then it's time for the TP. In terms of PR-able things, there are big amounts of possible things, ranging from simple to hard. Don't misread simple as "boring". For the actual code generation, one requires solid C++ knowledge - For the clang backend tool, for the generated C++ code, and overall.
<Papierkorb>
The Crystal wrapper is more about converting things back and forth, though this is considering the age of the project in a good place already I think. With the TP feature-set, focus will shift more on the Crystal-side, there's actually something really important to do - If you know about LibEvent's ins and outs.
relaxbox has quit [Ping timeout: 240 seconds]
<oprypin>
Papierkorb, there's one metric for complexity that I have - the amount of code. to me personally, no amount of documentation can compensate for it
<oprypin>
do you not understand that it is extremely hard for someone to understand the logic of the whole setup when the core parts are interspersed with newer features
<oprypin>
by core i don't mean in terms of separating code into parts, just in terms of what came first
<oprypin>
for someone who follows from the start and understands the evolution, documentation is not needed
<oprypin>
all i ask is code in any state from its earliest states
<Papierkorb>
Sure it's hard to get into a large codebase. However, I'm here and you can indeed ask what's going on. In fact, you should. I'll take note and, while responding, will later on write more about these parts. Hopefully, that'll help not only you, but also others
<oprypin>
i cannot work that way
<oprypin>
Papierkorb, for what reason are you unable to take the folder with code you currently have and dump it somewhere?
hightower has joined #crystal-lang
<Papierkorb>
For the reason that I worked hard, over a decade, to get to a state where I take pride in my code, and only release/deliver when I know that it's a show-case of my current abilities, and I can proudly proclaim "This thing may not be perfect, but it's polished and meets a (for my understanding) high quality-level".
<oprypin>
Papierkorb, share it privately? i won't judge
<FromGitter>
<bitmappergit> it's just really hard to understand
<FromGitter>
<johnjansen> let me rephrase, that could be ruby
bew is now known as bew78
<oprypin>
can confirm, runs on ruby
<oprypin>
i actually cant find any way in crystal to use both ARGV and put the program in stdin
<oprypin>
for ruby i did `ruby - coverage` and paste the program
<FromGitter>
<mgarciaisaia> Nice to see this tio.run supporting Crystal - didn't knew it
<oprypin>
mgarciaisaia, glot.io did earlier
<FromGitter>
<mgarciaisaia> 💙
bew78 has left #crystal-lang ["Leaving"]
<Papierkorb>
For the logs, d12195b4ab964b706ef13dbd71a60bcd94bb8d657d85ed918e48f2caf4492648 preview.tar.gz
bew78 has joined #crystal-lang
<FromGitter>
<bew> awesome! (any way poor gitter users could get access to it?)
<Papierkorb>
I simply posted the sha256 of the archive as timestamped proof of its origin. You know what linus once said? Let people mirror your stuff as backup? Thanks y'all.
<FromGitter>
<bew> huh sorry but I don't get it
<Papierkorb>
bew, also, no. It's a one-time thing. The public technical preview will be out in a few days at max however.
<FromGitter>
<bew> oh, ok no prob' !
<Papierkorb>
bew, posting the hashsum of that archive, before posting it to its recipient, acts for me as insurance, as proof of origin. I can proof that I'm the original author of the work. I can proof it by simply publicly sharing the link to the archive of that hashsum. This measure was never necessary in the past, and I hope that it will never be necessary to enact in the future.
<FromGitter>
<bew> I see, neat :)
<Papierkorb>
bew, The important bit of this thing is of course publicizing the hash to an audience. I just abused everyones eternal log for that. This is "Proof of Ownership" is pretty near in practice (and in theory, pretty far from) the blockchain network, where you do a "Proof of Work" (or other kinds) using a hash of similar style. In that case, the audience is the distributed network, and not some IRC channel ;) in any case, if I did pike your
<Papierkorb>
interest a bit, I want to encourage you to learn more about it. It's a huge treasure trove of good ideas (and bad implementations).
<FromGitter>
<bew> yeah I learned a bit on how blockchains actually works (for cryptocurrencies), but I never thought of other possible applications like this one. thanks for your details!
bew78 has quit [Quit: Leaving]
<FromGitter>
<mgarciaisaia> We should probably just stop implementing things, and be happy enough knowing that *ideally* they work awesome
<Groogy>
"Everything worked perfectly until QA added all the bugs"
<Papierkorb>
Business could be so nice, the customers really stink though. We should get rid of them and their requests to save money.
<FromGitter>
<johnjansen> Life would be great if only everyone would let me do whatever I want
alex`` has quit [Ping timeout: 255 seconds]
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
Yxhuvud has quit [Remote host closed the connection]