🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:07 reportable6 left 00:09 reportable6 joined 01:09 evalable6 left, linkable6 left 01:11 evalable6 joined 02:09 linkable6 joined 02:14 frost joined 02:18 frost left 02:28 vrurg left 03:57 frost joined 05:05 childlikempress joined 05:06 moon-child left 05:19 childlikempress is now known as moon-child 05:48 squashable6 left 06:07 reportable6 left 06:09 reportable6 joined 06:22 squashable6 joined 06:55 discord-raku-bot left, discord-raku-bot joined
nine Xliff: now I'm confused. The fix somehow broke your parallel toolchain? 07:09
07:32 nebuchadnezzar joined
Xliff nine: No. Bitrot did. It's been over 15 weeks since it was last used. 09:32
Today was the first successful parallel run since *Nov*
p6-GLib Suite compile times for v2022.02-108-gcd02552c9: 8941.6s (non-parallel) / 1409.57343595s (parallel) 09:34
Timings taken across 31 raku Projects 09:35
Note change of benchmark vehicle. Current stats are now: AMD Ryzon 9 5950x (16 processors, 32 threads, 3.4Ghz) 09:36
lizmat Files=1351, Tests=117115, 299 wallclock secs (35.88 usr 9.89 sys + 4158.16 cusr 335.24 csys = 4539.17 CPU) 09:37
nine Xliff: are you still using those long lists of -I? 09:40
Xliff Previous was Intel i9 10900 (10 core, 20 thread, 2.8Ghz) 09:43
nine: Yes 09:44
nine That's really costing you a lot of performance
Xliff nine: Irrelevant. There's no way to install them, so how else will it work?
nine Why is there no way to install them?
Xliff Until my issues with CURI are addressed, there's no way to handle the significant number of files without proper user feedback. 09:45
nine What issues?
Xliff CURI / zef is insufficient. Please see the dialog on 4655
nine: No proper user feedback during install.
I have work designed to address the issue, but it is still in progress. 09:46
I've investigated ALL of the options currently offered. They all fall short of where I'd expect Raku to be, at this point. 09:47
Question: How would you leverage existing CURI to handle a GUI based module installer?
If you can answer that one, I might reconsider. Please describe said mechanism in detail. 09:48
nine What are the unique requirements of a GUI based installer as opposed to a CLI based one?
And how does that relate to the build script we were talking about? 09:51
Xliff nine: Name a top 10 language without a GUI installer. 09:53
That is my point.
If Raku is going to grow, it will need to consider t he end user. End users use GUI installers. 09:54
One of the staples of a GUI installer is the bar graph.
How will you be able to leverrage current CURI to handle a bar graph?
Second question: Why does the list of -I directives affect performance? It sounds to me like a problem that needs to be resolved. 09:55
If it is not on your priority list, then please describe the issues involved and maybe I will add that to my list of things to investigate. 09:56
nine: Would 10:01
nine As to name a top 10 language without GUI installer: C
Xliff HAH! Installshield was originally written in C.
MSVC, but still C. It' s the largest installer in the worl! 10:02
s/worl/world/
nine But if that counts, then Raku has GUI installers, too. E.g. yast which you can use to install prepackaged Raku modules on openSUSE
Xliff Hmmm.... fair point. I'll then have to conceed C. 10:03
But there is a large difference between C and Raku.
C deals with unmanaged code. Raku is managed.
I would then say that comparing C to Raku is akin to comparing different fruit.
Just because C doesn't have one is no reason to conclude that Rakudo doesn't need one. 10:04
nine Well I certainly gave a valid answer to your original question ;) Anyway that's an unproductive tangent
Xliff I did say I conceded that point. :p 10:05
nine: My simple answer for CURI - Supply-based events.
I'll need to polish up what I have and submit it to problem solving, but that's probably not going to happen before the middle of spring. 10:06
I have a full dance card atm.
nine But what does all of this have to do with the long list of -I in your build script?
Xliff You brought that up. Not me!
Again, the long list of -i directives is due to the fact that I cannot install any of my projects due to the lack of user feedback in CURI! 10:07
nine No, I didn't? All I did was ask why you can't use installation instead of those -I
Xliff And I just said why I could not!
nine But -I doesn't give you any more feedback?
It just takes longer which makes the problem worse 10:08
Xliff Actually, there is no hard reason not to. More like a prerence.
nine: That's why the build scripts were written. To give me the proper feedback.
nine If it takes twice as long to compile and doesn't give you any more feedback than installation, then I just don't understand why you use it
But you can have the same level of feedback with installation 10:09
Xliff I have practically spelled out the reason for -I. You are still trying to find a reason for it. Almost as if your eyes are sliding over the reason I've just given.
nine: If you are about to speak on the RAKUDO_ variables, I've already touched upon that. NONE of them do what I would like. 10:10
I do have to complement lizmat for at least trying.
nine: What would be the problem for building a non-installed module repository at $*HOME/.rakudo/.precomp where all modules compiled via -I live? 10:11
That directory is then checked before all given -I directives for precompiled files.
This way you are not having to check all over the place.
nine I've just taken another look at build.sh (AFAIK the script we're talking about) 10:12
Xliff The way -I is currently implemented (as you've described) seems like you are bending over backwards to make it DELIBERATELY slow.
That's the way you've described it in #4655, at least.
And what did you find out about build.sh?
nine It does give you more feedback, that's true, because it has per-module output. Installation could give you per-distribution output, so quite a bit less. However I still wonder, if that isn't enough if compilation is a lot faster. Less wait time would mean less need for getting feedback, wouldn't it? 10:13
Xliff That particular script was built primarily for statistics. Its use as a project-build script is secondary. 10:14
nine With -I you _do_ have to check all over the place, regardless of where the precomp files are stored, because all the time you have to check if the sources have changed.
Xliff nine: Then why doesn't that apply to all Raku modules. Oh, you are keeping the sources with the .precomp, aren't you? 10:15
nine: Helpful hint. I think we are barking down two mutually exclusive tangents. 10:17
nine CURI uses an optimized storage format that avoids parsing JSON at all cost.
Xliff The -I build script is there for statistics.
For project installation, I'm not tied to it. It was the path of least resistance for compiling my code.
I would prefer to have CURI properly inform the user as to what is currently being installed. Something that it does not do. 10:18
I couldn't give a rats ass as to install speed. Speed does not mean that the user need not be informed as to what is happening to her system
Therefore t he current CURI implementation is incomplete, from where I stand. 10:19
I have something in the works that may address the issue, but it will be weeks to a couple of months before I have the time to complete it.
I suspect we can have a more productive discussion, then. 10:20
nine For the sake of the argument, lets assume that compilation is practically instantaneous. Since the installation call is per distribution, the installer knows that CURI is e.g. currently installing Glib. Since that is done faster than the user could even read the string "Glib", what more would they need? 10:21
Xliff Information as to what the "GLib" installation consisted of and or the time it took to install 10:22
You can't remove installation time from consideration. It should be reported or tracked. 10:23
nine The installer already knows what the Glib installation consisted of. The information is contained in the META6.json and is what the installer actually gives to CURI 10:24
And of course the installer can easily measure how long it took to install Glib
Xliff I'm Joe end user who just started with Raku. I neither know or care about a META6.json because I am just starting. I do care about how long it takes to install this project that got me interested in the language. And possibly the install time of its dependents. 10:25
I need to know this because I might want to consider installing this software on a wide variety of machines
With a wide variety of resources.
It would be nice to have that information so I am better informed on things THE RAKU PROGRAMMERS DON'T NEED TO KNOW OR CARE ABOUT! 10:26
Empasis mine because you have been ignoring that salient point this entire time.
nine I'm not sure we mean the same thing with the word "installer". Do you mean the user installing something (e.g. Joe) or the application that the user uses to install something (e.g. zef). 10:27
Xliff Does it matter? 10:28
A raku user, who has no need to become a raku developer, will not give a shit about META6.json. Why make them?
Currently the only way to install Raku software is via CURI (ala zef) 10:29
So there is only -one- installer ATM.
And it is flawed at the CURI core.
nine It does matter a lot. Because while you're right, that the user doesn't have to care about META6.json, an installer application does have to care. And since the installer application does have to process META6.json, it already knows what modules are contained in the distribution and can already display this information to Joe user 10:30
Xliff nine: Wait until I have a chance to write this up. Your arguments do not even begin to show me that you have an idea as to what my problem is.
nine So there's nothing CURI has to do to have the user know which modules were installed
Xliff nine: And that's where we disagree.
nine: And you can't see it. You are arguing on a tangent that I am not dealing with at the moment.
nine On which point exactly? Does the installer app not know the modules?
Xliff nine: On just about every point that I've raised THAT YOU'VE IGNORED! 10:31
So just stop. You aren't even close to addressing my issues. None of your questions matter to me.
nine Have you considered that you may not have actually tried to understand my points either? 10:32
Xliff I have. I have illustrated them to you over and over in this conversation. 10:33
You keep retreading backwards like you have not read them.
Look at my use case above. Pay CLOSE ATTENTION to what I am asking there.
Not a single WHIT of it is addr esseed by your questions.
10:36 Xliff left
nine What does WHIT stand for? Can't find it in the glossary 10:39
Oh, I guess it isn't an acronym 10:41
lizmat "a very small part or amount"
I hope Xliff will correct me if I'm wrong 10:42
the problem their facing is: installing a GUI based-app written in Raku taking very long
nine Know what? Just forget it. As I will any issues you may report. Getting shouted at by people one is trying to help is decidedly not -Ofun 10:43
lizmat indeed, it is not
2. Xliff wants to be able to report progress on the installation process
3. there is currently no way to do that 10:44
fwiw, I also find this annoying with e.g. installing modules with zef
case in point: try installing DateTime::Timezone :-)
*TimeZone
nine lizmat: sure. But I bet you wouldn't care anymore about progress reports if installation was just faster. 10:46
lizmat that would reduce the need for sure, but it will be a while before it is less than a few seconds for large module bases and their dependencies
I mean, even with modules installed, a re-compile of the core causes modules needing to be re-pre-compiled for some of my workflows 10:47
and that takes long enough to make a cup of tea in some cases :-(
releasable6 Next release in ≈3 days and ≈7 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
11:33 dogbert17 joined 11:38 TempIRCLogger left, TempIRCLogger joined 11:42 TempIRCLogger left 11:43 TempIRCLogger joined 11:48 Geth left 11:49 Geth joined 11:52 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left 11:53 TempIRCLogger joined 12:07 reportable6 left 12:09 reportable6 joined 13:03 vrurg joined 13:06 vrurg left 13:08 vrurg joined
Geth DBIish: eeb91eeb30 | (Vadim Belman)++ | lib/DBDish/Oracle/Native.pm6
Use OCI_THREADED for when creating environment

This simple fix allows to use individual connections per-thread whereas with `OCI_DEFAULT` 2+ connections per application are likely to cause crashes.		 13:20
DBIish: 041eb77d73 | (Vadim Belman)++ (committed using GitHub Web editor) | lib/DBDish/Oracle/Native.pm6
Merge pull request #218 from vrurg/threaded-oracle

Use OCI_THREADED for when creating environment
ugexe so leets add progress reports to everything 13:21
sometimes Joe wants to know why their map is so slow and just wants it to sent events telling them when it iterated 13:22
also each time a coercion occurs
we can make the entire language an event store even. maybe even the first one 13:24
vrurg ugexe: Sorry, I missed the previous discussion, it seems. But let me point at a difference: things like map and coercion are under user control. Module loading is not.
lizmat I agree we need to be able to provide some kind of event stream
ugexe we could easily find a more appropriate coparison that is equally absurd 13:25
lizmat but I think a prerequisite for this would be in-process pre-compilation
13:42 frost left 14:20 dogbert17 left 14:21 dogbert17 joined 14:54 discord-raku-bot left 14:55 discord-raku-bot joined
Geth DBIish: vrurg++ created pull request #219:
Prepare for zef ecosystem		 15:05
16:47 linkable6 left, evalable6 left 16:48 evalable6 joined 16:49 discord-raku-bot left, discord-raku-bot joined
nine The irony is that all the progress reporting infrastructure will make stuff even slower. I have sometimes pondered removing RAKUDO_MODULE_DEBUG, but its still useful too often. 16:56
17:48 linkable6 joined
lizmat true, but the seeing some progress will give people a better idea on how long it is still going to take 17:49
and that's also pretty important
18:07 reportable6 left 18:10 reportable6 joined
ugexe RAKUDO_LOG_PRECOMP is exactly for seeing "some" progress 18:21
the argument can't be the end user is left in the dark, it has to be that there isnt a complex event emitting system in place to... do almost the same thing 18:25
lizmat true: but you still have no idea how long it is going to take, as it only shows the one that is being pre-comped 18:39
ugexe how would an event telling you the same thing give you any more of an idea how long it will take? 18:40
i guess thats what my confusion mostly boils down to
lizmat because it doesn't tell you how many things it still needs to do
ugexe so if rakudo log precomp prefaced its output with how many modules it is about to precompile it would be fine? 18:41
lizmat I mean, it was just bolted onto the RAKUDO_MODULE_DEBUG machinery
that would be a start, yes
you could even envision driving off a progress bar off of that 18:42
ugexe you could do the same thing presumably with IO.watch or some such and no additional CUR machinery
lizmat hmmm.... 18:43
nine Sure you can. Already right now. Parsing the installation process' STDERR isn't that hard
lizmat do we know all of the precomp files that are going to be created beforehand ?
nine Sure. It's in the META6.sjon
lizmat recursively? 18:45
I mean, does the outer outer process know? 18:46
nine An installer only installs one dist at a time anyway.
lizmat ok, but what about re-pre-comping?
nine That's a completely different use case. 18:48
In just about any way
lizmat I guess :-) 18:55
BTW, if I install something with "zef install ." from a dist directory 18:56
should it re-precompile that module on first use without using any -I parameter ?
nine no 19:00
It will need to re-check dependencies, but that's much faster than full compilation. 19:01
lizmat well, then there's something wrong, because it *will* re-precompile in that case 19:02
meh, of course when I try to reproduce, it works :-( 19:04
I guess I'll get back to this when I can reproduce :-) 19:06
Geth DBIish/main: 4 commits pushed by (Rod Taylor)++, (Vadim Belman)++ 19:52
DBIish/main: ba45fbc2f2 | (Vadim Belman)++ | 4 files
Prepare for zef ecosystem

  - start using mi6 for release
  - keep auth/ver/api of the module in sync with META6.json
  - add Changes file
  - change auth to `zef:raku-community-modules`		 19:53
DBIish/main: c5b311c89d | (Vadim Belman)++ (committed using GitHub Web editor) | 4 files
Merge pull request #219 from vrurg/zef-ecosystem

Prepare for zef ecosystem
vrurg I have meet this note in NativeCall::TypeDiag with regard to &diag-functions: "REMOVED. It's now part of NativeCall" But it's not there. Any ideas? 20:18
Can't release DBIish because mi6 fails on xt/ where that is used. 20:19
Geth DBIish/main: c0e5c636dd | (Vadim Belman)++ | 4 files
Quickfix for xt/ tests

Relied upon diag-functions routine used to be provided by NativeCall::TypeDiag but which is long not there.
Needed for `mi6 release` which tries to run tests in xt/ too.
NOTE. It looks like nobody did xt/ testing in years since the last commit to NativeCall::TypeDiag is dated back to 2016! Perhaps it makes more sense to remove them altogether?		 20:59
DBIish/main: 6b01a57174 | (Vadim Belman)++ | 7 files
0.6.4
 21:01
23:45 benchable6 left, squashable6 left, unicodable6 left, committable6 left, bloatable6 left, tellable6 left, sourceable6 left, bisectable6 left, linkable6 left, reportable6 left, evalable6 left, coverable6 left, nativecallable6 left, statisfiable6 left, greppable6 left, notable6 left, quotable6 left, shareable6 left, releasable6 left 23:47 benchable6 joined, unicodable6 joined, evalable6 joined, notable6 joined, bloatable6 joined 23:48 reportable6 joined, squashable6 joined, tellable6 joined, quotable6 joined 23:49 linkable6 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!