<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vMGfS
<crystal-gh>
crystal/master ba5c2b0 Ary Borenszweig: Let `puts` and other printing methods return `nil`
ome has quit [Quit: Connection closed for inactivity]
<BlaXpirit>
uhm asterite, what's up with that commit? i really like that `p` returns the object itself, that allows plopping a `p` in the code somewhere for quick debugging without needing to add an additional line of code
<BlaXpirit>
`func1(p func2(p x))` and stuff
<BlaXpirit>
i'm sure in Ruby it has the same popular usage
<FromGitter>
<sdogruyol> @Blaxpirit i've never done that in my life
<BlaXpirit>
regardless of that, it's always returned the object, both in Ruby and Crystal, and I see no reason to break this
<FromGitter>
<bcardiff> I didn't new p return the object. I usualy use `expr` => `expr.tap { |e| puts e }` to print debug in the middle of the expression.
<BlaXpirit>
welp so you didnt know you needed this
<FromGitter>
<bcardiff> yeap. I was meant to say that I do find it useful that p return the arg. :-)
<FromGitter>
<bcardiff> In the playground I even instrumetn p/puts to show the arg values, since I didn't know that the return value was what I wanted to show in the side bar...
<Yxhuvud>
inserting p into a chain of stuff is helpful. having puts return self, perhaps not.
<Yxhuvud>
(it was added a few versions of ruby ago. 2.1?
<FromGitter>
<maiha_twitter> I agreed `each` returns nil. And it's useful that `p`, `pp` returns itself. I think this is a different problem.
<Yxhuvud>
yeah, p and pp is for debug printing primarily, and then it is useful to be able to just drop it in front of stuff. You can't always do it without ()s due to blocks getting in the way, but often enough.
<FromGitter>
<asterite> Hm, I think you are right. I never used it that way, but I understand this is for debugging (`p` and `pp` are for debugging). Would it be OK if I made `p` and `pp` return the objects, but keep `puts` as returning `Nil`?
<FromGitter>
<asterite> I can imagine `puts` in a real program, but `p` and `pp` are only for debugging
<FromGitter>
<maiha_twitter> +1
<Yxhuvud>
sounds about right to me
<FromGitter>
<asterite> @BlaXpirit ?
<FromGitter>
<bcardiff> +1 here
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vMGkb
<crystal-gh>
crystal/master d7c2f28 Ary Borenszweig: Let `p` and `pp` return the argument
<FromGitter>
<splattael> Elixir's `IO.inspect` also returns the args (also adopted from Ruby) so can easily add it to a pipe chain: ⏎ ⏎ ```23 ⏎ |> complex_operation ⏎ |> IO.inspect ⏎ |> more_complex ⏎ |> IO.inspect``` ⏎ ⏎ That's fun [https://gitter.im/crystal-lang/crystal?at=586e5d52aa6be0472f0f2b16]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
<FromGitter>
<mjago> +1
pawnbox has quit [Ping timeout: 246 seconds]
pawnbox has joined #crystal-lang
gloscombe has joined #crystal-lang
mark_66 has quit [Remote host closed the connection]
<BlaXpirit>
@asterite sounds great though not sure how much sense it makes to return the object if there are multiple arguments to p and pp
<rkeene>
To bootstrap Crystal, what version of Crystal do I have to compile first (with a non-Crystal compiler) ?
<FromGitter>
<bararchy> @asterite How the `.id` thing works ? if waj explanation is correct in the StackOverflow question it's quite hard to "eval" the string into an actual operation
pawnbox has quit [Ping timeout: 248 seconds]
pawnbox has joined #crystal-lang
<Papierkorb>
rkeene: That'd be a ride, you'd have to use the ruby based compiler and then gradually compile versions. Do you have a GCC cross-compiler for the target platform on your host?
<rkeene>
Papierkorb, Yes (my entire distribution is cross-compiled), but I'm not trying to cross-compile Crystal, just compile it to USE as a cross-compiler
<Papierkorb>
bararchy, ASTNode#id returns the identity of the given thing. example: macro eval(string); {{ string.id }}; end eval("puts 1")
<Papierkorb>
rkeene: You mean, you want to build a cross compiler which spits out binaries for the target platform from your host platform?
<rkeene>
Yes
<rkeene>
Just like I do for programs written in other languages, like C, C++, and Go, right now.
<rkeene>
(I have around 305 packages in my Linux distribution, the vast majority of which are compiled for the host platform (Linux/x86_64) no matter what the build platform is)
<Papierkorb>
rkeene: I guess asterite or others would be of more help, but the gist is that you "just" need to pass the right LLVM arguments to the `build` command (See `crystal build --help`).
<rkeene>
Papierkorb, Using terms like "target" and "host" are somewhat confusing here, FWIW -- the correct terms would be "host" and "build" (unless you really DO mean "target" and "host", in which case I am not trying to build a canadian cross-compiler)
<rkeene>
Papierkorb, I can't run Crystal since I haven't compiled it yet. I haven't compiled it yet because I don't have a Crystal compiler. I need to compile the Crystal compiler before it relied upon Crystal.
<rkeene>
I do the same thing with Google's Go -- compile Go 1.4-bootstrap before compiling the real version of Go
<rkeene>
I just need to know what the equivelant of Go 1.4-bootstrap for Crystal is, since I couldn't find it documented
<rkeene>
(None of this is cross-compiled, this is all for building a cross-compiler for Linux/x86_64 on any platform)
<Papierkorb>
The best equivalent is most likely the old compiler written in ruby, you can find it in the `ruby` branch. But that's getting real far out of my realm...
<rkeene>
Any idea what release that was ?
<wmoxam_>
rkeene: ancient. You probably don't want to do that :D
wmoxam_ is now known as wmoxam
wmoxam has quit [Changing host]
wmoxam has joined #crystal-lang
vivus-ignis has joined #crystal-lang
<Papierkorb>
Yes it's ancient, even in terms of Crystal, you'd have to iteratively compile later compilers until you get to the current version
<rkeene>
wmoxam, Option #2 is just not to compile Crystal (which I'm fine with -- I didn't have any definite plans for using it yet, just thinking about building some software in it -- I'll just use Go if Crystal isn't available)
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vMGWd
<rkeene>
wmoxam, This is just cross-compiling Crystal using Crystal. I don't have Crystal.
<Papierkorb>
Why don't you have it anywhere? You most likely have a machine capable of running one, which would make the process incredibly easier
<wmoxam>
rkeene: okay, do you have another machine or VM where you can access a crystal compiler?
<wmoxam>
or a friend who can do it for you?
<rkeene>
Papierkorb, Because this is a build process for a Linux distribution (albeit you could be compiling it on a Windows box), so it has to be self-contained, otherwise builds are not reproducible.
<rkeene>
wmoxam, It wouldn't help me build the exact same version 10 years from now, which is my distribution support lifecycle.
<wmoxam>
rkeene: why not?
<rkeene>
Every time I build it, I need it to be built from scratch in the same environment identically. I take care of this by compiling the entire environment first.
<rkeene>
wmoxam, Because there's no way for me to coordinate that across time -- I can't guarentee external entities will exist in the future. Right now, and for everything else, things are self-contained.
<wmoxam>
you will need to have the source + object file in order to build it. There is no other way
<wmoxam>
no other reasonable way at least
<Papierkorb>
Well, assuming you have a C compiler, compile LLVM, ruby, then use the ruby compiler to compile an by then seriously ancient version of crystal, and then iteratively compile versions until you get a reasonably recent one
<rkeene>
Papierkorb, I need to know what those versions are.
<wmoxam>
Papierkorb: not reasonable IMO ;)
<wmoxam>
you'll need an ancient version of Ruby + gems too
<rkeene>
If the Crystal compiler seriously requires multiple hops (dumb -- nobody else does) then I'm fine with that, but I need to know what they are.
<rkeene>
wmoxam, That's fine, my entire process deals with multiple ancient versions fine
<Papierkorb>
If in doubt, successively in their release rkeene. I don't know if it's documented anywhere how old of a compiler is acceptable to compile a more recent compiler
<FromGitter>
<schovi> Hi guys, I wanted to ask for long time, why is there another "language" instead of Crystal itself?
<Papierkorb>
schovi, another language?
<rkeene>
wmoxam, Ruby Gems are so convoluted that I have an entire process for creating their build scripts
<wmoxam>
AFAICT you can't compile 0.20.3 with 0.19.4
<FromGitter>
<schovi> @Papierkorb I edited it. In macros :D
<wmoxam>
and there are multiple breakages like that along the way
<Papierkorb>
schovi, IRC doesn't support edits (thank god it doesn't)
<wmoxam>
so you'd need to discover what they all are
<Papierkorb>
schovi, Macros are /not/ their own language
<wmoxam>
and that's def not documented anywhere
<rkeene>
wmoxam, So it's not documented anywhere how to actually build Crystal ?
<wmoxam>
rkeene: not in the way you are proposing
<rkeene>
Well, in the way a sane distribution would build it
<Papierkorb>
schovi, Macros are expanded at compile-time, which uses {% .. %} and {{ .. }} as only additions, and in those, it's mostly Crystal. Exception would be the `for x in y` syntax for those, which I'd love to see gone :)
<FromGitter>
<schovi> Papierkorb: They are in some way. Instead of using stdlib, there is special "syntax" and some functionality reimplemented.
<rkeene>
What does Nix do ? They have similar goals to me.
<Papierkorb>
schovi, they're similar to C macros in some way (and not so much in others). Anyway, their syntax is near to Crystal, and it's documented. For syntax, see the language docs, for methods, see the stdlib docs
<rkeene>
Oh... I see.. Nix also doesn't package Crystal
<rkeene>
Well, I think you guys have sufficiently convinced me to give up and not worry about supporting Crystal
<Papierkorb>
rkeene: Our equivalent to Go 1.4 bootstrap is the ruby compiler. I don't see much difference in that regard, it's an ancient version of the compiler there too
<wmoxam>
👍🏻
<rkeene>
Papierkorb, But you won't (can't) tell me what version I need and there are a bunch of other versions needed along the way that are also not documented (Go has documented which version of the compiler you need to bootstrap -- Go 1.4-bootstrap)
<Papierkorb>
rkeene: What version? The one that's most recent in the ruby branch
<Papierkorb>
Whichever version that turns out to be
<wmoxam>
Papierkorb: it would be v difficult to to it that way
vivus-ignis has quit [Quit: vivus-ignis]
<Papierkorb>
wmoxam: I think we made more than clear at this point
<Papierkorb>
+that
<rkeene>
Right, which is why I suspect Nix also gave up on this and decided not to include Crystal
<Papierkorb>
What's Nix
<wmoxam>
rkeene: Is anyone packaging Crystal at this point?
<rkeene>
wmoxam, Nobody sane, since there's no way to build it :-D
<wmoxam>
it's still early days
<wmoxam>
rkeene: there is! I even wrote a port
<rkeene>
Papierkorb, https://nixos.org/ it's a package mangement system (nixpkgs) and Linux distribution
<rkeene>
wmoxam, Yep, and yours is unsupportable
<Yxhuvud>
rkeene: I'm quite certain people would accept pull requests that specify which versions of different things are necessary to bootstrap.
<Papierkorb>
And that relies on a C compiler? Isn't that somewhat recursive?
<wmoxam>
rkeene: OK
<rkeene>
Papierkorb, The very first thing my Linux distribution (which is not Nix, but has similar goals) is to build the exact same C compiler (a cross-compiler in fact, since everything is always cross-compiled to avoid contamination from the build host) in addition to setting PATH to something only inside the build directory
<Papierkorb>
I mean, your decision, but betting on Go1.4 being a viable solution in 10 years seems to be a gamble too
<rkeene>
Well, the same exact version of Go 1.4-bootstrap that compiles today will compile in 10 years is almost certainly true.
<Papierkorb>
Same goes for the ruby compiler?
<rkeene>
And since I cache everything by hash (SHA256) both locally and as part of my distribution download process (building packages have no network access after the download function completes), centrally, I'll get the exact source 10 years from now.
<rkeene>
Exactly
<rkeene>
What release is that ?
<Papierkorb>
The one in the `ruby` branch
<Papierkorb>
Really, it's git
<rkeene>
And it's version number is ... ?
<rkeene>
I won't pull from Git directly since it's too hard to serialize into my cache.
<rkeene>
git-archive isn't useful either, since the SHA256 changes everytime you run it.
<rkeene>
I can pull from GitHub's .tar.gz download of a particular commit, since it is stable
<Papierkorb>
You trust that GH is around in 10 years?
<rkeene>
I don't have to
<rkeene>
Once I download something, it is stored by SHA256 forever associated with the project
<rkeene>
In 10 years, I'll have the exact same SHA256-identified object available
<FromGitter>
<asterite> if I remember correctly there's no easy way to boostrap from the compiler written in Ruby. In some middle versions we made some changes that simply can't be compiled by going from one version to another (like, changing the internal representation of String)
<FromGitter>
<asterite> rkeene I don't think you'll be able to do what you want
<FromGitter>
<schovi> Papierkorb: ok thanks for explanation :)
<rkeene>
asterite, I'm fine jumping through multiple versions rather than a single bootstrap version
Kug3lis has joined #crystal-lang
<rkeene>
asterite, But I don't know what those verions are.
<Papierkorb>
schovi, I get that macro {{ code }} looks a bit weird at first, but you'll understand in no time when you get used to it. Or maybe you don't even need them for some time ;)
<FromGitter>
<bararchy> rakeene: why don't just install the compiler on a supported system with static libs, then, compile the compiler staticlly, and you have a standalone bin that can be disterbuted
<rkeene>
asterite, This seems to just list every release
<FromGitter>
<asterite> @schovi Macros are another language because for them to be crystal you'd have to compile them first, and that would be terribly slow. In general macros are interpreted. For example in Nim they are interpreted. In Elixir too, but it's easier there because the whole language is interpreted and they have a fast VM. In fact in Nim they also wrote a VM just for macros. To be the exact same language as Crystal we'd need to write an
<FromGitter>
... interpreter for the whole language...
<FromGitter>
<asterite> rkeene yes, since we are 0.x there's no guarrantee that a bump between minor versions will be backwards compatible
<rkeene>
asterite, So I have to start with 0.1.0 and compile every release from there ? There's no releases that didn't break compiling Crystal ?
unshadow has joined #crystal-lang
<wmoxam>
:D
<rkeene>
bararchy, Because that cannot be automated in a reproducible way
<FromGitter>
<asterite> rkeene I honestly don't know, I never imagined someone will need to do that because they can just download the latest compiler
<rkeene>
Well, they can download a BINARY for the latest compiler, distributions build things from source for good reasons...
<wmoxam>
rkeene: you keep saying that, but I don't know why
<rkeene>
wmoxam, Because it is true.
<wmoxam>
🆗
<rkeene>
Anyway, I'm sufficiently demoralized about this and will just drop the plan to have Crystal-written code
<unshadow>
rkeene: why can't you automate a build on a static lib ? also that is a one time only thing, for that you can use the bin to just compile the compiler for your other dists
<Papierkorb>
You could at least give an actual reason rkeene. Everything else is unfair. People do that wmoxam, cause 1) they compile anything that's FOSS cause they do 2) be less platform dependant (imho the only reason)
<FromGitter>
<asterite> rkeene do you know how rust does that?
<rkeene>
wmoxam, There is no "external" system when building -- there's only the build system. The build system can be many different platforms, so a static library in the source control will not work for whatever platform you are building on
<FromGitter>
<asterite> what's the build system? gcc?
<rkeene>
asterite, No, I haven't looked at Rust -- I know how Go does it
<FromGitter>
<asterite> Do you compile that Go-1.4 with gcc?
<rkeene>
asterite, My build system is one particular to my Linux distribution (which is internal to my company, for a product we produce that runs our Linux distribution which is an appliance-style application)
<rkeene>
asterite, Yes (the same version of GCC/binutils too, since part of the bootstrap builds the same compiler environment)
<FromGitter>
<asterite> Do you compile GCC from source?
<rkeene>
Yes
<rkeene>
And binutils, and glibc
<FromGitter>
<asterite> Using which compiler? And that compiler is also compiled from source?
<FromGitter>
<asterite> I mean, GCC is bootstrapped...
<rkeene>
(Though glibc only for the cross-compiler)
<rkeene>
GCC is built using whatever C compiler you have initially
<FromGitter>
<asterite> ?
<FromGitter>
<asterite> Can't you install a pre-compiled crystal binary in that build system
<rkeene>
No, since there's not one for most of the platforms I build on
<FromGitter>
<asterite> Well, since you trust that initial C compiler, I don't see why you can't try a pre-installed crystal binary that you installed in that build system
<rkeene>
(They all have C compilers -- enough to build GCC, though)
<FromGitter>
<asterite> Sorry, I don't think I'll be able to help, or think that there's any reasonable way to do it :-(
<rkeene>
Yeah, that's what other distributions have concluded as well as far as I can tell
<rkeene>
Not a particular problem, I just liked Crystal better than Go... but Go it is
<rkeene>
This also means I can drop LLVM, since I was only building it for Crystal
<FromGitter>
<asterite> Hmm... one thing you could do, is to compile Crystal to an LLVM IR file (.ll). Then you'd use llvm to compile that to an executable. An .ll file in this case should be very similar to a .c file you are needing... right?
<rkeene>
This would make it REALLY hard to upgrade between versions of Crystal -- right now, for most of my packages I just increment the version number and update the SHA256 and the new version is built (testing happens later, as part of the CI process -- for every commit a cluster of VMs are built, since it's a cluster-OS, and integration tests run)
<Papierkorb>
Most packages are not compilers I guess
<rkeene>
Doing the proposed implementation, I'd need to preprocess it on a special box
<rkeene>
Papierkorb, Compilers aren't special -- they take input and convert it to output, much like "sed"
<Yxhuvud>
asterite: he would still have to specify llvm version, because the .ll isn't stable, right?
<FromGitter>
<asterite> Yes
<Papierkorb>
Well asterite just presented you with a shortcut, we told you twice at least how to do it completely without. A modern GCC may also not build with an ancient GCC
<rkeene>
My entire build system is a directed graph, so Crystal depends on LLVM, so if LLVM changes then Crystal would get rebuilt
<rkeene>
Papierkorb, I'm building with a rather old GCC at this point -- I build GCC 4.9.3 as part of the initial build (i.e., after you do ./configure && make one of the first things built is Binutils, then GCC 4.9.3) -- I've not run into a problem yet with a version incompatibility on any OS I compile it on
<Papierkorb>
4.9 isn't that old, it's in the last 5 years I think?
<Papierkorb>
That's not much considering the lifetime GCC has seen as project
<FromGitter>
<smarr> @RX14: regarding the benchmark implementation (discussion Dec. 27), most of the benchmarks were first implemented in Smalltalk, and then ported to Java. Exceptions are Havlak and Json, if I recall correctly. They were Java benchmarks first.
<rkeene>
It's something I believe will continue to compile for the next 10 years on any host someone builds this on, but it's also not cutting edge.
<Papierkorb>
Sure, as most FOSS projects are rather conservative, only few have actually started using C11/C++11. Considering that, it'll work for a long time for that, and if you're Debian or even ScientificLinux style of conservative, that'll work for the next 30 years
<FromGitter>
<smarr> @asterite @RX14 @Yxhuvud, proposals or PRs for improving the Crystal code would be very welcome here: https://github.com/smarr/are-we-fast-yet/issues sorry, am not really tracking this channel, and am in a hurry at the moment :-/
<RX14>
rkeene, so is it a technical limitation why you can't download a crystal release and bootstrap from there, or is it a security thing?
<rkeene>
I'm not sure what point you're getting at though... My point is that I regularly compile my OS on Linux/ARM (again, it only builds for Linux/x86_64) to ensure that there is no leakage from the build OS, to ensure quality and reproducibility across time and changes in the build system
<rkeene>
RX14, There's no pre-compiled Crystal for some OSes I build my Linux distribution on
<RX14>
yes so you precompile your own?
<rkeene>
Right, and I'd do that as part of the build system
<rkeene>
And to do that, it needs to be automated
<rkeene>
And to be automated I need to know how to build it...
<RX14>
you would download a latest release for x86 and build a crystal package from source for x86
<RX14>
then use that to cross-compile for arm
<RX14>
host that somewhere and do the same for arm
<RX14>
or wait for manastech to sort out the CI situation
<RX14>
then we'll have nightlies for all platforms
<rkeene>
And then I'd have to have special build boxes, pets, that I need to maintain forever
<rkeene>
For every OS I try to build on
<RX14>
you wouldn't have special build boxes
<RX14>
you would manually cross-compile a compiler release for all platforms you want
<RX14>
host it somewhere
<RX14>
then it's the same as if crystal had a release for that platform
<rkeene>
And they, of course, couldn't compile newer versions of Crystal
<rkeene>
So everytime I upgraded Crystal I'd have to go through this whole process over and over again manually
<RX14>
every release is compiled from the previous
<rkeene>
Times the number of build systems I use
<RX14>
it doesn't have to be manual
<RX14>
no
<rkeene>
Right, but since the boxes aren't persistent and aren't pets they don't have the intermediate versions
<RX14>
you have the previous version on every box
<RX14>
so you can build the next on every box
<rkeene>
You said I didn't have pets ?
<rkeene>
So I *DO* need special build boxes ?
<RX14>
yes but if you HAVE the previous version as a package
<RX14>
surely you keep your packages somewhere
<rkeene>
Nope
<RX14>
thats dumb
<rkeene>
Everything is built as part of a straight dependency graph
<RX14>
and crystal's depgraph depends on the previous version
<RX14>
which is something your system will have to deal with eventually
<RX14>
so why not create a solution now
<rkeene>
If the package hasn't changed and none of its dependencies have changed, it's not rebuilt -- from scratch (it's a 1.2MB tarball that exapands to 30MB and requires 20GB to build) every package's source is downloaded (via SHA256) and built according to its dependecy graph (e.g., ./configure && make -j12 builds out all the things)
<rkeene>
If Crystal dependency graph depends on every previous version it's just too much work to build Crystal
<rkeene>
And it's dumb to keep around the build artifacts for the individual packages -- if they need to be rebuilt, they can be (bit-for-bit identical, yay quality, even 10 years from now)
<Papierkorb>
Ok, how do you do it with Go btw? Go1.4 is outdated, you then use that to build a later release? Latest release?
<rkeene>
This is convienent because what you care about 10 years from now, from a support perspective, isn't if you HAVE the binaries, it's whether or not you can produce a patched version of the binaries in response to a bug
<rkeene>
Papierkorb, Yes -- I build Go 1.4-bootstrap then build Go 1.7.4
<Papierkorb>
And that's guaranteed for a decade to work for the latest version?
<rkeene>
It's guarenteed to work for Go 1.7.4 with Go 1.4-bootstrap
<rkeene>
With GCC 4.9.3
DeBot has quit [Remote host closed the connection]
DeBot has joined #crystal-lang
<rkeene>
(Which is all built as part of the top-level make)
<RX14>
does rust have this problem?
<rkeene>
I haven't looked at Rust
<RX14>
they seem to have compiler "stages"
<RX14>
yeah rust just autodownloads a recent "stage0" release to build with
<rkeene>
Probably a good reason to avoid Rust too (since that will definitely fail, after the download function finishes, there's no more network access)
<wmoxam>
or you could just download stage0 along with the source code
Kug3lis has quit [Read error: Connection reset by peer]
<rkeene>
Also a possibility, but I'd have to look at what that involves -- but I have no plans for including Rust any time soon
<RX14>
go is a pretty conservative language which is probably why it can be built from an old compiler, but rust and crystal are not
Kug3lis has joined #crystal-lang
<wmoxam>
RX14: that sort of compatibility is totally doable for Crystal too (post 1.0 especially)
<RX14>
not really before 1.0
<wmoxam>
it would have to be made a priority
<RX14>
it's not possible before 1.0
<RX14>
and it still won't be easy after
<wmoxam>
yeah, no point when the language is still evolving
<RX14>
as we'll still be adding features
<wmoxam>
RX14: true, but new features don't have to be used in the compiler codebase
<RX14>
limiting compiler development to only stuff the 1.0 compiler compiles would be a bit stupid
<rkeene>
Well, we just won a $1.5B contract with this product so if I think of something that we need Crystal for it's possible I could sponsor making being able to compile Crystal a priority through funding its development
<wmoxam>
only stupid if compatibility isn't a priority
<Papierkorb>
Well you could make a point that each minor release compiler needs to be compilable with the first minor release of a major track
<RX14>
rkeene, if you fund the CI stuff we can build on all platforms
<Papierkorb>
Or some rule like that
<rkeene>
But right now, I was just wanting to include it to think about how it could be done
<RX14>
which means you could just download a bootstrap compiler for all your platforms
<rkeene>
RX14, That doesn't solve my problem since the compiler that's being compiled with the bootstrap compiler may be an older version (10 years ago) than the bootstrap compiler
<RX14>
no there would be a bootstrap version specified for each package
<RX14>
so for the 0.20.4 package you would update to say "i want to build 0.20.4 with 0.20.3"
<RX14>
and it would dopwnload 0.20.3 and compile 0.20.4
<RX14>
for whatever platform
<rkeene>
Maintaining those build artifacts for 10 years for every platform*every version sounds real wasteful
<RX14>
nah
<RX14>
a package per release per platform?
<RX14>
that does not sound that big
<RX14>
lets go crazy and call it 50mb per release for futureproofing, and 30 supported platforms, that's like 30*3*12 if we have 12 major releases with 3 point releases each
<RX14>
thats only 52GiB
<RX14>
which is in the grand scheme of things, nothing
<rkeene>
It's larger than my entire distribution's current build requirements (again, 1.2MB tarball, 30MB expanded, 20GB to build -- product is installer ISO)
<RX14>
i know people who host 3TiB of image files because they have fun doing it
<RX14>
52GiB is nothing
* wmoxam
orders a 2TiB drive to store his video games
<rkeene>
Anyway, I have Go right now, but I'll try to remember Crystal
<Papierkorb>
2TiB?
<Papierkorb>
wmoxam: 3+5TiB in LVM. Never delete anything :D
<wmoxam>
😅
<RX14>
btrfs > lvm :)
<Papierkorb>
btrfs crashed for me (..twice on two machines 6 months apart), also I do like that LVM is below the FS level
<RX14>
what distro?
<Papierkorb>
Arch x64
<RX14>
i've never had a problem with btrfs on arch
<RX14>
interesting
<Papierkorb>
I think we talked about this just two weeks ago
<rkeene>
BtrFS is the only filesystem I've ever lost data with
<Papierkorb>
and I didn't even do anything fancy with it
<rkeene>
(Aside from hardware failure)
<Papierkorb>
So eh, let's give it another 5 years or so, I'm happy with ext4 mostly
<RX14>
btrfs is pretty watertight as long as you don't use raid5 or raid6
<rkeene>
And I've been doing Linux/UNIX long long time
<rkeene>
RX14, Or span it across disks with different BIO properties
<rkeene>
(Which is how I lost data -- I added two disks to a pool, but they had different sector sizes)
<rkeene>
(BtrFS happily reported my data was written, but only wrote some of it)
<Papierkorb>
What's the benefit of btrfs doing the LVM part?
<Papierkorb>
"Just because" doesn't sound so great as a FS feature
<RX14>
that it's actually simple and just works
<FromGitter>
<redcodefinal> @asterite Thank you!
<Papierkorb>
Can't complain at all w.r.t that with LVM, it was super easy to set up
<rkeene>
Well, LVM is simple -- the main benefit is not the LVM part but the other things that can leverage the LVM part, like snapshots
<Papierkorb>
I just like the UNIX principle. One job. And then stacking stuff. LVM does the logical drive stuff, ext4 knows how to store data in a tree. How neat.
<rkeene>
LVM snapshots are terrible
<RX14>
the thing is for me that btrfs does all I want lvm to do
<rkeene>
Papierkorb, EXT4 lacks checksumming, which is the killer feature I use ZFS (now) for
<Papierkorb>
Dunno, I use LVM mainly to span FS across drives, I don't like having multiple mountpoints
<RX14>
CoW is nice
<Papierkorb>
Right, but ZFS has a weird license, so nah, don't bother. I'm not running a server, it's a desktop, so I don't have issues server operators face
<RX14>
i mainly store media on my btrfs drives so being able to use cp --reflink is nice
<RX14>
rkeene, i'm currently using btrfs over 3 drives of totally different capacity and make, not sure how to check sector sizes
<rkeene>
It's possible this bug has been fixed -- but the data-lossing due to BtrFS bug wasn't the only reason I switched away from it
<rkeene>
There's also: 1. The bug where mount() can hang unless you mount() from a newer kernel first if you shutdown improperly (my solution there was to use UML with a newer kernel to do a mount() and then a clean umount() before having my kernel do the mount()); 2. EXTREMELY slow disk I/O for some workloads (~200KB/sec when using it to host QCOW2 images for QEMU+KVM)
<rkeene>
3. Extremely slow xattr performance for Ceph (25% the speed of XFS -- for example)
<RX14>
rkeene, for pt 2, even with cow disabled on the file?
<Papierkorb>
And then you forget a file
<RX14>
and you get slow performance
<Papierkorb>
But iirc you could also apply it on a directory
<RX14>
which you notice
<RX14>
then fix
<rkeene>
I don't remember, it's been atleast a year
<RX14>
with 1 command
<RX14>
rkeene, it shouldn't be that slow with chattr +C file
<rkeene>
It's entirely possible that such functionality did not exist at the time
<rkeene>
But I do not recall
<RX14>
a year ago? no way
Kug3lis has joined #crystal-lang
<RX14>
chattr +C has been around forever
<rkeene>
I doubt it's been around forever -- I started using BtrFS in 2010 (and I'd been using ZFS for a long time before that) and if it was present it wasn't documented
<RX14>
well at least 3 years then
<RX14>
2010 was early for btrfs
<rkeene>
As late as 2015 I still had to do all kinds of workarounds for BtrFS
<RX14>
how old was the kernel?
<rkeene>
2015-04-13 18:14:28 [26be160eb0] Updated to latest 3.18.x kernel to deal with deadlock bug in BtrFS on unclean shutdown
<rkeene>
2015-05-05 15:29:28 [8ef88fa03c] Added "btrfs-mount-umount" script to perform a clean mount/unmount of BtrFS filesystems under a working kernel
<RX14>
hmm
<rkeene>
2015-03-30 19:53:46 [62c1b8128a] Closed ticket [6920eb9bf7650ee7|6920eb9bf7]: <i>Dashboard kernel panic in BtrFS</i> plus 4 other changes
<rkeene>
2015-12-03 18:23:06 [9f1db72799] Downgraded to btrfs-progs 4.1.2, btrfs-progs 4.2 through 4.3.1 do not boot with EXTLINUX
<RX14>
maybe i've just been lucky
<RX14>
btw, for your comparisonm page, btrfs does support deduplication rkeene
<rkeene>
It didn't in 2010
<RX14>
okay
<RX14>
btrfs's on-disk format wasn't even stable in 2010
<rkeene>
URL to documentation for it ? I haven't looked in a while
<rkeene>
BtrFS also somewhat gained support for parity... but from what I've read it's just a way to lose your data
<RX14>
yeah they found out that it all had to be rewritten recently
<RX14>
so they disabled creating volumes with it in btrfs-progs
<rkeene>
I also do other weird things like multipathing and disk encryption (using a smartcard to decrypt a header that holds the AES key)
<rkeene>
This ends up confusing lsblk and blkid too
Kug3lis has quit [Read error: Connection reset by peer]
<rkeene>
(The only way to get sane output I've found is to use lsblk -s -- otherwise "lsblk" just skips stuff)
Kug3lis has joined #crystal-lang
gloscombe has quit [Quit: Lost terminal]
Kug3lis has quit [Read error: Connection reset by peer]
LiberalSquash has joined #crystal-lang
LiberalSquash has left #crystal-lang [#crystal-lang]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
Kug3lis has joined #crystal-lang
pawnbox has quit [Ping timeout: 245 seconds]
soveran has quit [Remote host closed the connection]
Kug3lis has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bcardiff has joined #crystal-lang
bcardiff has left #crystal-lang [#crystal-lang]
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
soveran has quit [Ping timeout: 240 seconds]
vivus-ignis has joined #crystal-lang
acheron[m] has joined #crystal-lang
Philpax_ has joined #crystal-lang
vivus-ignis has quit [Quit: vivus-ignis]
Philpax_ has quit [Ping timeout: 246 seconds]
bjz_ has joined #crystal-lang
A124 has quit [Remote host closed the connection]
<RX14>
@sdogruyol released 0.1.2 of multipart.cr
A124 has joined #crystal-lang
bjz_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<FromGitter>
<mjago> I do ```ptr = Pointer(Int32).malloc(10000)``` and then pass ptr to a library which expects an int pointer. And I can index ptr ```ptr[123]``` so is ptr an Array and is this all valid? (it seems to work)
<Papierkorb>
I just tripped over something I consider "weird". I used my lovely macro to turn a struct into a Bytes slice pointing to it to read into it: `pointerof({{ variable }}).as(UInt8*).to_slice(instance_sizeof({{ type }}))` Must be some alignment thing, but the read was always +8 Bytes off. But when I Bytes.new(instance_sizeof(TheStruct)), read into that, and then hack-cast it back to the struct, it works fine
<Papierkorb>
Yeah the struct is Packed and everything. The same macro works fine with multiple other structures.
soveran has quit [Remote host closed the connection]
bcardiff has quit [Quit: bcardiff]
<RX14>
thats weird
Kug3lis has joined #crystal-lang
<Papierkorb>
Err, sorry, the read was correct, I dumped the Bytes slice with the same macro afterwards. But the interpretation was off. Don't wanna investigate now, but I left the offending call commented to look later
Kug3lis has quit [Read error: Connection reset by peer]