Can this be in a number/humanize require? The std keeps growing and base compile times are getting slower and slower.

@asterite methods dont affect compile times at all unless they are used. This method is unused unless you use the benchmark harness then you're doing a release build anyway and you don't care.

@RX14 Almost: the parser still has to parse it and build an AST for it. Every bit counts.

@asterite I don't think that extra tiny bit is worth the nuisance to have to require number/humanize. I'd like to encourage people to use these formatter methods for human-readable output and hope they'll be used in many Crystal applications 👍

The prelude.cr/std should be shrinked generally I think. Every single time you compile some crystal file, all the methods in every require in prelude.cr get parsed. Even if you only use 3 or no methods of all these thousand methods.

time(crystal emptyfile.cr --prelude=empty); time(crystal emptyfile.cr)

real    0m0.349s
user    0m0.156s
sys     0m0.094s

real    0m2.157s
user    0m1.594s
sys     0m1.219s

@r00ster91 this is not the place to discuss prelude.cr.

@straight-shoota Could you use descriptive commit messages for fixups? Just having fixup! with no context makes it really hard to review commits.

@asterite The first line of the commit message needs to reference the targeted commit, otherwise !fixup doesn't work. Descriptions are only visible in the second line.
Maybe I'm missing something but I can't find a way to prevent that.

Is fixup! a convention or something?

@asterite if you use git rebase --autosquash, then it is magic that automatically make git rebase do the right thing.

@straight-shoota You can refer to refspecs instead. see https://robots.thoughtbot.com/autosquashing-git-commits

@yxhuvud That still doesn't allow custom descriptions in the first line of the commit message, does it?

@straight-shoota Ah, no. That is a pity.

@asterite it's not just a convention, it's an official part of git. git commit --fixup=sha1 and then git commit --autosquash master.

@asterite judging by --stats, parsing uses less than 1% of the time in any program.

I'm entirely unconcerned by parse time. By the time parse time is the compiler bottleneck, we will have won.

That's because parse stats just show the time for parsing the main file. When a require is processed, that parsing time happens in top-level, I think.

At one point all parsing was done in parsing, but since that has changed the parsing step has very little use now as stats info.

Regardless, it's not just parsing time, it's holding the AST nodes in memory for the entire compilation.

But yeah, let's not care. Let's wait for the magical solution that will enable incremental compilation :-)

@asterite Parse and top level together for the compiler use 473 milliseconds out of 28.618 seconds. That's 1.65%. It's still not a bottleneck. For cached builds, that increases to about 2.5% of time.

I'm not saying compiler performance isn't useful, but this is picking the wrong thing to worry about.

Sounds good.

What do others think about IEC vs JEDEC? (see thread #6314 (comment))

Will this make it into 0.27.1?

@straight-shoota what do you think about organizing all the humanize code in a separate file/folder?

@bcardiff he's on holiday...

@bcardiff done

Hmm, seems that lately CI bugs increased in frequency.

CI is still broken @bcardiff

hmm, it's the same issue as in #7179.

Lot's of cc: error: ****.o: No such file or directory

Can those failing builds be reproduced? Are they using docker? If we can't reproduce these locally it'll be very hard to figure out what has gone wrong. And I'm almost sure it has nothing to do with a specific PR, I'm almost sure it's something about the CI (disk, memory?)

The CRYSTAL_CACHE_DIR in the CI uses the /tmp inside docker. That was done a long time ago maybe there is something special about /tmp (a cleanup could be triggered?) although its writes are performed over the container as any other folder.

Let's see if using the default location helps at both PRs.

spoiler: it didn't work

Usually /tmp is mounted as tmps, which is RAM. If both the storage and the compilation use RAM, we can have issues if the RAM is full. I haven't found anything more.

It seems that the issue is not /tmp but somewhere when emitting the .o.tmp files the process stops. Leaving partial .o.tmp files and some missing .o oddly enough the missing files seem to be consistent.

Running in CircleCI make std_spec FLAGS=--no-debug seems to make things pass. Always.

I don't know if it is something about the debug information itself or the file size or something with the memory buffers.

That's all I could find.

I suggest trying to run a debug build if the compiler with debug output (puts, after each .o is generated, check if the file is there later, etc.). Otherwise I don't know how can we debug this.

Rebased and ready to ship.