»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg camelia perl6: ... | irclog: irc.perl6.org | UTF-8 is our friend! Set by sorear on 25 June 2013. |
|||
00:00
telex joined,
rurban1 joined
00:06
rurban1 left
00:16
Psyche^ left
00:17
Psyche^ joined
00:32
btyler joined
|
|||
[Coke] | lue: github.com/tadzik/Template-Mojo/issues/4 | 00:38 | |
Anyone talk to supernovus outside of irc? | 00:39 | ||
01:02
ajr_ left
01:03
rurban1 joined
01:05
bbkr_ joined
01:07
bbkr left,
rurban1 left
01:11
genehack left
01:23
leont left
01:39
eternaleye left
01:42
eternaleye joined
01:55
araujo left
01:56
tgt left,
araujo joined
02:04
rurban1 joined
|
|||
TimToady | should there be a Promise state of Unwanted that tells the code trying to fill a promise that it no longer needs to try? | 02:07 | |
02:08
rurban1 left
|
|||
TimToady | (my brother-in-law Mark asks: if you're racing a bunch of promises, and you only want the first one that finishes, how do you stop the others from wasting energy?) | 02:08 | |
btyler | SIGGIVEUPYOULOST :) | 02:09 | |
TimToady | one could, I suppose (with proper documentation) have an agreement that either the promiser or the user can get the vow and keep/break the promise, and if the promiser's promise is broken by the user, stop looping or whatever | 02:10 | |
or the promiser gets the vow but puts it somewhere public, if it wants to be cancelable by the user | 02:12 | ||
on that subject, can the user of channel $c call $c.done? I suspect the method (originally called .close iirc) was envisioned only for use by the sender, but can a channel be shut down by the reader? | 02:15 | ||
or do we need to have something corresponding to a vow for a channel (like maybe a "quest" object, sort of an extended vow :) | 02:17 | ||
02:21
genehack joined,
lue left
02:22
colomon joined
|
|||
BenGoldberg | What happens if there are two or more users of a channel, and only one of those users stops wanting it's output? It would be bad to call $c.done too early, I think | 02:22 | |
TimToady | well, at some point civility is required | 02:23 | |
but I wonder if we're setting ourselves up for a "core leak" | 02:24 | ||
how does Go handle this? | |||
obviously if you don't trust the code you're running, you shouldn't be allowing it to use up threads without resource limits of some kind, but even assumning non-malignant intent, you can get long-running promises started accidentally, and you'll like to have some way to deal with that maybe | 02:27 | ||
02:29
kurahaupo_ joined
|
|||
TimToady | or do we just develop a culture of adding timeout promises to everything? is there any way for an anyof to signal the "promise collector" that a "promise collection run" is desirable? :) | 02:29 | |
02:31
[Sno] left,
[Sno]_ joined
02:32
jnap left
|
|||
TimToady | is there a need for some kind of fratrcidal anyof that breaks all the eggs that didn't hatch first? | 02:32 | |
*tric | 02:33 | ||
energy usage is a concern to various companies running servers | 02:35 | ||
02:36
bloonix left
|
|||
TimToady | I suppose you can do a "lazy race" with a bunch of channels, as long as they can exert backpressure and specify how much buffering they desire | 02:37 | |
a certainly amount of speculative execution can speed throughput, but too much of it just runs up your electric bill, not to mention your air conditioning bill | 02:40 | ||
TimToady imagines a Google barge in the Arctic that doesn't use much electricity to cool the servers, and then imagines a pun on "sunk cost" | 02:42 | ||
TimToady probably needs to douse his head in some cold water... | |||
(or do a bit less speculative execution...) | 02:43 | ||
02:44
_ilbot left
02:46
_ilbot joined
02:50
lue joined
|
|||
TimToady | ((it would seem post-headache branefuzz is not the best time to do design)) | 02:51 | |
japhb_ | It is certainly desirable to make M-of-N combinators that when satisfied stop the (M+1)..N work-in-progress. | 02:53 | |
TimToady | stop and/or suspend | 02:54 | |
after the first page of results :) | 02:55 | ||
TimToady takes pity on wife, who pitiously and/or pitilessly asks him to cook dinner | 02:57 | ||
02:59
raiph joined
|
|||
japhb_ | Sure. Though I was thinking rather of managing latency long tail. | 03:01 | |
(Without generating vast continuing load that is known to not affect results already decided._ | |||
03:04
rurban1 joined
03:09
rurban1 left
03:13
kaleem joined
03:29
fridim_ joined
03:48
kaleem left
03:49
guest313 joined
04:05
rurban1 joined
04:06
leont joined
04:10
rurban1 left
04:11
preflex_ joined,
ChanServ sets mode: +v preflex_
04:13
preflex left,
preflex_ is now known as preflex
04:25
guest313 left
04:42
araujo left
04:55
xinming left
05:03
xinming joined
05:06
logie left
05:08
kurahaupo_ is now known as kurahaupo
05:12
logie joined
05:23
ponbiki left
|
|||
kurahaupo tries to remember which bot does store-and-replay messaging (for the benefit of timezone outcasts) | 05:27 | ||
TimToady | preflex: help | 05:34 | |
preflex | try 'help help' or see 'list' for available commands | ||
TimToady | preflex: help list | ||
preflex | list - show available plugins | ||
TimToady | preflex: list | ||
preflex | Botsnack: [botsnack]; Cdecl: [cdecl]; 8ball: [8ball]; excuses: [excuse]; Factoid: [+, -, ., ?, delete, get, store]; Help: [help, list]; Karma: [++, --, karma, karmabot, karmatop]; Nickometer: [nickometer]; Nickr: [nickr]; PlokiRE: [re]; Seen: [seen]; Sixst: [6st, ordinal]; Tell: [ask, clear-messages, messages, tell]; Rot13: [rot13]; Quote: [be, quote, remember]; WCalc: [calc, wcalc]; Version: | ||
[version]; XSeen: [xseen]; ZCode: [zdec, zenc] | |||
05:34
logie left
|
|||
lue | preflex: zenc test | 05:37 | |
preflex | test | ||
05:37
SamuraiJack__ joined
05:46
jercos left,
jercos joined
|
|||
moritz | good morning | 05:58 | |
06:06
rurban1 joined
06:11
rurban1 left
06:16
BenGoldberg left
06:19
xinming left,
xinming joined
06:36
[Sno]_ left
07:05
kaleem joined
07:07
rurban1 joined
07:10
SamuraiJack joined,
SamuraiJack__ left
07:12
rurban1 left
07:15
daveec left,
daveec joined
07:23
sivoais left
07:26
sivoais joined
07:29
araujo joined
07:33
fridim_ left
07:45
dmol joined
07:52
btyler left
07:53
darutoko joined
|
|||
GlitchMr | runsvdir -P /etc/service log: /run: line 2: cd: /data/svn/commitbit: No such file or directory ./run: line 2: cd: /data/svn/commitbit: No such file or directory | 07:59 | |
hm | |||
08:08
rurban1 joined
|
|||
moritz | GlitchMr: pasting some random command line and error message without any context into the channel is neither interesting for us, nor a good base for discussion | 08:09 | |
08:09
zakharyas joined
|
|||
GlitchMr | From ps aux. | 08:09 | |
moritz | ... on? | ||
GlitchMr | I'm not sure if service running on feather should have error messages in arguments. | 08:10 | |
moritz | well, I'm sure | ||
(that they shouldn't) | |||
08:10
Celelibi left
08:12
thou left
08:13
rurban1 left,
nnunley left
|
|||
moritz | GlitchMr: now that you found it, what are going to do with it? | 08:14 | |
08:41
FROGGS joined
08:50
salv0 joined
08:55
darutoko left
08:58
hummeleB1 left
09:09
rurban1 joined
09:13
rurban1 left
09:18
FROGGS[mobile] left
09:21
grondilu left
09:29
kivutar joined
09:32
xinming left
09:34
xinming joined
09:36
dakkar joined
10:01
darutoko joined
10:04
tgt joined
|
|||
jnthn | TimToady: Yes, we very much need a cancellation mechanism. | 10:06 | |
10:07
ponbiki joined
|
|||
jnthn | TimToady: Though, anyof should probably not use it. A combinator that explicitly races, along with a ..timeout one to factor out that very common idiom, would, though. | 10:09 | |
10:10
rurban1 joined
|
|||
moritz | A branch, a tag, and a reflog walk into a bar. The bartender says, "What is this, some sort of rebase?" | 10:10 | |
10:10
kurahaupo is now known as kurahaupo_mobile
|
|||
arnsholt | o/ | 10:14 | |
10:14
rurban1 left
|
|||
moritz | arnsh\olt | 10:14 | |
arnsholt | ^_^ | ||
jnthn | arnsh\o/t | 10:15 | |
FROGGS | hi :o) | ||
moritz | FRO/GGS! | ||
colomon | \p | 10:17 | |
errr | |||
moritz | c\olomo/n | 10:18 | |
jnthn | r: "\p" | ||
camelia | rakudo-parrot 75c45f: OUTPUT«===SORRY!=== Error while compiling /tmp/BsdHz5pnVmUnrecognized backslash sequence: '\p'at /tmp/BsdHz5pnVm:1------> "\⏏p" expecting any of: statement list prefix or term p…» | ||
..rakudo-jvm 75c45f: OUTPUT«===SORRY!=== Error while compiling /tmp/ti0BmLVtsgUnrecognized backslash sequence: '\p'at /tmp/ti0BmLVtsg:1------> "\⏏p" expecting any of: statement list prefix or term pref…» | |||
jnthn | Thought so :) | ||
10:18
kivutar left
|
|||
FROGGS | mo/ritz! | 10:19 | |
10:24
darutoko left,
ponbiki left
10:33
darutoko joined,
xenoterracide left
10:35
ponbiki joined
|
|||
FROGGS | jnthn: when storing modules in a sort-of database, do you have any wishes about precomp or extra information that should go along with it? | 10:46 | |
like, compiler version or something else? | |||
jnthn | FROGGS: compiler version is one good one, 'cus if that changes the pre-comp is invalidated | 10:47 | |
FROGGS | for all backends? | ||
jnthn | Yup | 10:48 | |
FROGGS | k | ||
jnthn | It's 'cus of the BS | ||
You link against the setting. | |||
FROGGS | ahh, yes | ||
jnthn | Which links against the bootstrap and MOP, which in turn is against a particular NQP... | ||
10:49
dmol left
10:52
fhelmberger joined
10:53
berekuk left
|
|||
FROGGS | lizmat: atm it tries site first: github.com/tadzik/panda/blob/maste...ler.pm#L20 | 10:56 | |
and for CompUnitRepo.install I think panda just calls its .install with: %dist-info, $from-path, $to-path-without-prefix | 10:58 | ||
or maybe it just passes the %dist-info along will to-be-installed files along the "subdirectory" they should appear in | 10:59 | ||
dunno how we're going to support Makefiles btw | |||
maybe we need some sort of standalone installer that can be invoked like ExtUtils | 11:00 | ||
still, you need to supply (trustworthy) information about the distribution that is going to be installed | 11:01 | ||
11:08
darutoko left
11:10
cibs left,
rurban1 joined
11:15
ssutch left,
rurban1 left
11:20
[Sno] joined
11:21
raiph left
11:22
cibs joined
11:40
dmol joined
|
|||
timotimo | ohai | 11:44 | |
11:55
hummeleB1 joined,
pernatiy left
12:11
rurban1 joined
12:16
rurban1 left
|
|||
timotimo | i had a dream where some big news site showed a story about an open source developer from finland having the nickname "timotimo1" because obviously some horrible commoner has taken "timotimo" | 12:27 | |
moritz literally lols | |||
jnthn | lol | 12:28 | |
tadzik | :D | 12:31 | |
timotimo | huh, it occurs to me, that that may very well be an expression of my imposter syndrome | 12:33 | |
tadzik | great. I got it and now everyone has it | 12:34 | |
imposters! | |||
timotimo | wow, vi hart's newest video about logarithms is pretty stunning | ||
jnthn | bbl & | 12:38 | |
lizmat | FROGGS: wrt to standalone installer: that is what CompUnitRepo.install should do | 12:43 | |
note that the first parameter to .install is the *source* to be installed | 12:44 | ||
*not* a filename | |||
.install should check the pod for module name / auth / version info and fail if it can't find the data it needs to install the module | 12:45 | ||
and create a pre-compiled version if it thinks that's necessary | 12:46 | ||
FROGGS | lizmat: what if a distribution ships other data than source code too? how should a command line tool know which dist/auth/ver it is? | 12:52 | |
lizmat | hmmm... do you have examples ? | 12:53 | |
12:54
dmol left
|
|||
lizmat | just to be able to think of use cases | 12:54 | |
FROGGS | example: perl6-debug ships a batch file, so you can actually type `perl6-debug` | ||
there is no pod :/ | |||
so, an "ExtUtils::CompUnitRepo --install" would need a hash of information directly from e.g. panda | 12:55 | ||
lizmat | hmmm... maybe the source parameter could be a hash of some sort | 12:56 | |
FROGGS | like when the CompUnitRepo wants to store the source location of the distribution, only panda knows where it got the dist from | ||
feels a bit icky | |||
lizmat | I see panda as a thin client of CompUnitRepo | 13:00 | |
so we need to put any needed functionality somehow in an API in CompUnitRepo | |||
maybe .install is a bit too simplistic | 13:01 | ||
;-) | |||
13:02
dmol joined
|
|||
FROGGS | depends on what it should install... it can either handle single files (of whatever type) or distros | 13:04 | |
lizmat is thinking | 13:09 | ||
.oO( what are you sinking about? ) |
|||
13:12
rurban1 joined
|
|||
FROGGS | *g* | 13:13 | |
german cost guard :o) | |||
13:16
rurban1 left
13:17
ajr joined,
ajr is now known as Guest74822,
Guest74822 is now known as ajr_
13:20
tgt left
|
|||
lizmat | ok, thought about it | 13:32 | |
.install is simple enough | |||
it takes *one* file and installs that | |||
because that is what the system needs to know when it wants to -use- it | |||
the "database" in the top dir should only keep information that is needed to be able to *execute* the code | 13:33 | ||
that database needs to be lean and mean | 13:34 | ||
any additional introspection should be optional and probably live in a different database | |||
so the oneliner should only be used to install a single file | 13:35 | ||
if a distro needs to install multiple files, it should call the oneliner multiple times | |||
FROGGS | sure, but the installer needs to know all about the distro it belongs to | 13:38 | |
even if it is a one-file-distro | |||
and especially if not | |||
lizmat | hmmm.. would we allow installation of pre-compiled bytecode ? | 13:40 | |
FROGGS | why not? | ||
lizmat | I guess we would | ||
FROGGS | like perl6-debug compiles itself using a Makefile | ||
lizmat | indeed... so .install can't in that case find out what it is it's installting | ||
FROGGS | you would install the executable and the source then | ||
maybe we would even install the needed things to rebuild it on demand | 13:41 | ||
13:41
tgt joined
|
|||
lizmat | but we need to keep remembering this: CompUnitRepo is what is needed to be able to *find* code for execution | 13:42 | |
nothing more | |||
and more specifically: find using the "use" command (and friends) | |||
FROGGS | it is not that easy | ||
lizmat | nothing else | ||
finding code to be executed ? | 13:43 | ||
FROGGS | who is in charge to install other files that belong to a dist? | ||
lizmat | not the CompUnitRepo, is what I just decided and will put into the spec :-) | ||
FROGGS | I am thinking about File::ShareDir now btw | ||
you do: use Foo::Bar(v1.0.2..*), and somehow this must match a File::SharDir lookup | 13:44 | ||
so an installed module can ask: Where is my stuff? | |||
lizmat | indeed: a compunit should be able to tell where it came from | 13:45 | |
FROGGS | I don't wanna have two installers, one for source code, and another for bytecode and other shared files | ||
lizmat | hmmm... | 13:47 | |
FROGGS | as I may have mentioned: IMO the CompUnitRepo is in charge to install a distribution (including (compiled) stuff from installation process) | ||
13:48
rindolf joined
|
|||
lizmat | so your saying, it's the CompUnitRepo's responsability to make sure that the database for looking up -use- files is as lean as possible | 13:48 | |
while granting it the possibility to have another database with much more information | 13:49 | ||
Hmmm.. I would think that the information the CompUnitRepo's database would live in memory anyway | |||
13:49
kivutar joined
|
|||
lizmat | perhaps even preload all @*INC CompUnitRepo's at startup, as to provide a "frozen" image of the outside during execution | 13:50 | |
13:50
kaleem left
|
|||
lizmat | so maybe we should free up whatever parameters we thought about with .install | 13:51 | |
because it's always going to be an "external" process doing the install | |||
so maybe we should just spec what is going to be needed for ::Installation | 13:53 | ||
aka, the "old" CPAN-like installation | |||
hmmm.. but would we allow modules to be installed by something like dpkg in the same directory as being serviced by ::Installation? | 13:54 | ||
I guess not, right ? | |||
FROGGS | lizmat: we don't need to freeze anything during execution for -use-, since that is compile time... | 13:56 | |
13:56
kaare_ joined
|
|||
FROGGS | question is: if you require something, should that take the newest database there is? I'd say so | 13:57 | |
lizmat | indeed, a require should reload if it sees that the database in memory is out of date with the one on disk | ||
FROGGS | lizmat: I'd give dpkg its own tree with its own database (maybe even with a debiadn specific database format) | ||
lizmat | I guess even a -use- should do that | 13:58 | |
FROGGS | so you newer install to the debian tree (aka vendor) using panda | ||
never | |||
never* | |||
lizmat | ah, ok | ||
*phew* | |||
FROGGS | :o) | ||
sorry, I am a bit distracted atm | 13:59 | ||
lizmat | so am I, actually | ||
FROGGS | the next thing is that we should spec that if a module installs a binary, it is not guaranteed that it will be the only version there is, and may get the version-number appended by default | 14:00 | |
our auth, for that matter | 14:01 | ||
or just get a hash | |||
14:01
tgt left
14:02
tgt joined
|
|||
lizmat | well, -use- will just ask the CompUnitRepo for candidates matching the given longname/ver/auth/from | 14:02 | |
so it's the CompUnitRepo's responsability to favour binary versions over source version or not | |||
FROGGS | I am not talking about use, more about executing a program | ||
like, perl6-debug, panda, ... | |||
p6doc | 14:03 | ||
if I install three versions of perl6-debug, clearly the best one should be in PATH (if that bin dir happens to be in path) | |||
but what is the best one if they all come from different auths? | |||
lizmat | in my view, that lies outside the responsability of CompUnitRepo, but in yours not, so I'm trying to adapt | ||
FROGGS | yeah, I am thinking about the whole installer thing, maybe CompUnitRepo is just one part of it :o) | 14:04 | |
lizmat | I'm going to see sno this evening, at the Niederrhein.pm meeting | ||
FROGGS | (an important one of course :o) | ||
lizmat | well, as I said, I wanted to keep CompUnitRepo as simple as possible, to reduce RAM/CPU requirements | 14:05 | |
FROGGS | yes, we don't need to blow that up | ||
we can have other parts that care about the rest | 14:06 | ||
lizmat | otoh, loading a compilation unit may be such an intensive task, that we could actually be a lot fatter in CompUnitRepo before anybody starts to notice | ||
still, I think leaner from the start is nearly always better | |||
FROGGS | yes | ||
btw, I think we should split rip the install part out of the code that is active while locating modules to use them | 14:08 | ||
s/split// | |||
14:08
tgt left
|
|||
FROGGS | gah, my english is terrible :( | 14:08 | |
lizmat | well, that's another reason I wanted to keep that simple :-) | 14:09 | |
so it wouldn't be a lot of code | |||
.install could just be a stub that requires the necessary code and does the right thing | 14:10 | ||
away for half an hour& | |||
FROGGS | jnthn: if we had a huge database of installed modules with a lot of information... I guess it would make sense to compile something for use/need/require? | 14:13 | |
14:13
rurban1 joined
|
|||
FROGGS | jnthn: so that we can just deserialize it and have a hash, only with the information we would need? | 14:13 | |
so we don't have to parse json or whatever at that point for example | 14:14 | ||
14:15
leont left
14:17
rurban1 left
14:21
colomon left
14:26
iSlug joined
14:29
smash_ is now known as smash
14:32
PacoAir joined
|
|||
jnthn | FROGGS: Perhaps, yeah. I guess that we get to keep this format under our control, rather than it being spec? | 14:37 | |
FROGGS | jnthn: that is an implementation detail, yes | 14:38 | |
it is even specific to a given module loader (aka CompUnitRepo) | |||
jnthn | ok | 14:39 | |
FROGGS | but it would be nice if this format survives a rakudo upgrade/rebuild | ||
hmmm | 14:40 | ||
or we rebuild that cache when rebuilding racudo | |||
rakudo | |||
jnthn | Well, or it detects it's out-dated on first "use" it has to process and re-builds then or something. | 14:41 | |
FROGGS | that would work too | ||
btw, I imagine that we put that CompUnitRepo in src/core along with the libraries.cfg in root dir, and include CompUnitRepo as the last thing in the setting | 14:43 | ||
14:44
kaleem joined
14:47
btyler joined,
bluescreen10 joined
|
|||
lizmat | FROGGS: agree with that last statement | 14:48 | |
FROGGS | k | 14:49 | |
14:49
berekuk joined
14:55
Gwyxx joined
|
|||
lizmat | FROGGS: hmm... what's libraries.cfg ? | 14:57 | |
15:02
jnap joined
15:04
logie joined
15:06
kaleem left
|
|||
dalek | ecs: 0dd084d | (Elizabeth Mattijsen)++ | S03-operators.pod: Small change in hash name to avoid confusion |
15:07 | |
lizmat | TimToady: been looking in the spec for the place where map { } is specified | ||
I can't find it :-( | |||
method map, no problem | 15:08 | ||
hmmm. I guess S32/Containers:326 mentions it | 15:09 | ||
15:13
darutoko joined,
salv0 left,
rurban1 joined
15:17
colomon joined
15:18
rurban1 left,
nnunley joined
15:20
ajr_ left
15:21
ajr joined
15:22
ajr is now known as Guest52379,
Guest52379 is now known as ajr_
|
|||
FROGGS | lizmat: libraries.cfg is the resident version of -I/--install | 15:27 | |
15:29
FROGGS left
|
|||
dalek | ecs: dabb21e | (Elizabeth Mattijsen)++ | S32-setting-library/Containers.pod: Spec the listless map { } |
15:30 | |
lizmat | FROGGS: but why can't I find that file anywhere on my system ? | 15:31 | |
15:35
salv0 joined
15:39
ajr_ left,
darutoko left
15:42
woolfy left,
brrt joined
15:44
dmol left
15:45
scottp_ joined
15:47
Ulti_ joined
15:48
Juerd_ joined,
pmichaud_ joined,
masak_ joined,
zakalwe_ joined,
BooK joined,
zakalwe_ left,
zakalwe_ joined,
Hor|zon_ joined
15:49
tgt joined
15:51
darutoko joined,
sorear_ joined,
[Sno] left
15:52
ivan``_ joined,
scottp left,
zakalwe left,
tadzik left,
pmichaud left,
masak left,
Juerd left,
ivan`` left,
BooK_ left,
Ulti left,
sjohnson left,
Yappo__________ left,
Hor|zon left
15:53
Juerd_ is now known as Juerd
|
|||
lizmat | Niederrhein.pm& | 15:53 | |
15:53
lizmat left,
brrt left,
salv0 left
15:56
thou joined
15:57
kaare_ left
15:59
prammer joined,
jeffreykegler joined,
sjohnson joined
16:00
Yappo__________ joined,
tadzik joined
16:01
salv0 joined
16:03
fridim_ joined
16:06
kaare_ joined
16:09
sjohnson left,
sjohnson joined
16:12
FROGGS[mobile] joined
16:14
rurban1 joined
|
|||
FROGGS[mobile] | lizmat: that file would be new when my changes get merged | 16:15 | |
16:19
rurban1 left
|
|||
timotimo | FROGGS[mobile]: are there long-term plans for rakudo-p5? | 16:19 | |
FROGGS[mobile] | timotimo: yes, there are | 16:20 | |
timotimo | you're doing S11 for now, and then back to p5? | ||
FROGGS[mobile] | that is my plan, yes | ||
jnthn | .oO( When somebody isn't trying to distract him with even moar to do... :) ) |
16:21 | |
FROGGS[mobile] | I hope that the test cicle gets shorter when we have moar | ||
because after every change I often have to spectest, which takes 40min on four cores | 16:22 | ||
timotimo | ouch :( | ||
FROGGS[mobile] | and then at some point diakopter++ wants to have that parser | 16:24 | |
diakopter | o_O | ||
timotimo | you mean the integration of perl5 into moarvm? | 16:25 | |
FROGGS[mobile] | :o) | ||
timotimo | is any of you going to the chaos communication congress in hamburg this year per chance? | 16:26 | |
FROGGS[mobile] | timotimo: yes, when the first step (not inlined code) wollen probably not need it | ||
timotimo: no | |||
jnthn | The first step is gonna be knitted? :D | 16:27 | |
FROGGS[mobile] | Bah! | ||
mobile phone typing sucks :p | |||
jnthn | timotimo: Not me, my only two remaining events this year are Nordic Perl Workshop and Build Stuff | ||
tadzik | not LPW? | 16:28 | |
FROGGS[mobile] | (Build Stuff)++ | ||
jnthn | tadzik: No, 'fraid not. | ||
tadzik: My work schedule is nuts. I'm only making NPW 'cus it's just a short train journey away. | 16:29 | ||
tadzik | I see | ||
jnthn | Woulda been fun to do LPW, though. It's always a great time. | ||
Ah well, it's yearly. :) | |||
tadzik | I was considering going | ||
FROGGS[mobile] | what is LPW again? | ||
jnthn | FROGGS[mobile]: London ... | ||
timotimo | london perl workshop | ||
tadzik | that would've been like 12th flight this month though, I'm starting to hate those :P | ||
FROGGS[mobile] | ahh yes | ||
jnthn | tadzik: Yes, while I technically could squeeze it in, I'm feeling kinda the same about travel :) | 16:30 | |
FROGGS[mobile] | I always hate flighs | ||
diakopter | EMOARFLIGHTSPLEASE | ||
tadzik | I miss trains. Trains are so fun | 16:31 | |
jnthn | Yeah, I do train when I can. | ||
tadzik | hah | ||
I see what you did there :P | |||
jnthn | But not always practical. | ||
timotimo | so what you're trying to say is ... "i like trains"? | ||
jnthn | :D | ||
tadzik | :D | ||
zzzzzzumm | |||
jnthn | hah, I was thiking about "I like trains" :) | ||
tadzik | now diakopter gets that joke too :P | 16:32 | |
diakopter | no, llama, no | ||
16:40
dmol joined
16:42
kaleem joined,
FROGGS joined,
FROGGS[mobile] left
|
|||
timotimo now can't get the thought of obama singing "i like change" out of his head | 16:42 | ||
tadzik imagines obama with his head opening like that of canadians in South Park, so he can sing out of it | 16:43 | ||
16:44
zakharyas left
|
|||
diakopter | PIE FLAVOR | 16:45 | |
16:45
raiph joined
|
|||
tadzik | isn't that Flavour? :P | 16:46 | |
diakopter | FEED ME PAPER | 16:47 | |
THERE'S NO DOG THERE | |||
I AM YOUR SANDWICH | |||
TimToady | and you pronounced PIE wrong | ||
16:48
fhelmberger_ joined
|
|||
diakopter | oh wait, this isn't a camera | 16:48 | |
WHY WAIT | 16:50 | ||
16:51
berekuk left
|
|||
diakopter | hello mine turtle. hello. | 16:51 | |
16:51
fhelmberger left
|
|||
diakopter | no because I work at teh muffin factory | 16:51 | |
tadzik | funny, it always sounded like "ze muffin factory" to me | 16:53 | |
16:53
fhelmberger_ left
|
|||
TimToady shakes his head for various reasons | 16:54 | ||
FROGGS thinks that music is one of the best | 16:55 | ||
moritz | or drying your hair! | ||
diakopter | I'm gonna do an internet ... MUSIC | ||
moritz | ok, my hair isn't long enough for that to make any sense | ||
diakopter | 3p6gXgiVEzY | 16:56 | |
FROGGS | hehe | 16:59 | |
moritz: mine almost is by now :o) | |||
16:59
ajr joined
17:00
ajr is now known as Guest8089
|
|||
TimToady | I believe the DSM-5 has a category for this channel...probably several categories... | 17:00 | |
17:00
Guest8089 is now known as ajr_
17:04
GlitchMr left
|
|||
timotimo | lamecia pls | 17:07 | |
jnthn | Did we start on advent calendar signups yet? | 17:09 | |
tadzik | yes | ||
hurry up, while there are still some slots :) | 17:10 | ||
jnthn tries to find it | |||
Oh...there it is | |||
uh, yeah, hot competition for slots here :P | 17:11 | ||
jnthn wonders what he's done in the last year and could talk about... :) | |||
FROGGS | humm | 17:12 | |
I should probably write about S11 | |||
and v5? | |||
17:12
kaleem left
|
|||
jnthn | Good ideas. | 17:12 | |
I guess I could do one about JVM. | |||
As in, Rakudo on JVM | 17:13 | ||
FROGGS | and parallism | ||
jnthn | Yes, that too | ||
FROGGS | and one about moar perhaps | ||
dalek | : 948d9d4 | jonathan++ | misc/perl6advent-2013/schedule: Take three slots. |
17:15 | |
17:16
fhelmberger joined
|
|||
jnthn | FROGGS: There's moar moar hackers than me, so I think maybe somebody else might pick that up... | 17:16 | |
FROGGS | yeah, maybe somebody does :o) | ||
17:16
GlitchMr joined,
[Sno] joined
|
|||
jnthn | If we were to put a Moar one towards the end of December we stand a good chance of having Rakudo on MoarVM running stuff by it. | 17:16 | |
17:16
xinming left
17:17
xinming joined
|
|||
jnthn | oh, I shoulda maybe put my name on those entries, so folks know I'm on the hook for 'em... | 17:17 | |
dalek | : b64fb21 | jonathan++ | misc/perl6advent-2013/schedule: Mark who's doing my days. |
17:18 | |
kudo-star-daily: e25a847 | coke++ | log/ (5 files): today (automated commit) |
17:19 | ||
rl6-roast-data: 483c822 | coke++ | / (5 files): today (automated commit) |
|||
17:20
Celelaptop joined
|
|||
FROGGS | jnthn: I think that "we" are on a good trak about perl6-m :o) | 17:20 | |
17:20
rurban1 joined
|
|||
jnthn | I may well get an hour or two for it tonight. We'll see. | 17:21 | |
Got ahead on the $dayjob stuff yesterday, but then lost a chunk of today to anesthetic and drilling... | 17:22 | ||
:/ | |||
[Coke] | Ow. | ||
FROGGS | uhh :o/ | ||
youtube: "Larry Wall - That Goes Without Saying (or Does It?)"++ | 17:24 | ||
dalek | ecs: c5b7d73 | larry++ | S17-concurrency.pod: winner ~~ s/nobody/wait 0/ |
17:25 | |
17:31
jnap left
|
|||
jnthn | Hmm. | 17:32 | |
Guess that works. | |||
TimToady | the problem with using anyof is that the degenerate case of timeout isn't guaranteed to poll | ||
jnthn | Poll? | 17:33 | |
TimToady | anyof($p1, $timer) can just give you the timer promise if it's 0 without checking $p1 | 17:34 | |
jnthn | Ah, true. | ||
TimToady | whereas winner's 'wait 0' guarantees to be checked last | 17:35 | |
jnthn | Well, it doesn't give you anything per se. | ||
anyof is just kept with True and it's up to you to go look at what that means. | |||
TimToady | right, but it's a funny little race condition there | ||
might be harmless, might not | 17:36 | ||
jnthn | The fact it doesn't give you back a promise and makes you decide what to check is part of what helps make it most likely harmless. :) | ||
17:36
fhelmberger left
|
|||
TimToady | I thought it does give back a promise, just a different one | 17:36 | |
jnthn | Yeah, sorry, misspoke | 17:37 | |
It gives you one, but when it's kept it's just kept with True. | |||
17:37
fhelmberger joined
|
|||
TimToady | anyway, we need something like winner if we're going to set up gladiatorial winner semantics | 17:37 | |
jnthn | As opposed to giving you the promise/value that made it be considered as kept. | 17:38 | |
TimToady | which winner can do, but is not required to | ||
btw, I'm assuming we're demoting winner from statement_control to a mere (but fancy) term | 17:39 | ||
jnthn | In general, though, I think anyof/allof are useful in the cases where you want to do something afterwards which is not based on the results of the input promises. | ||
As in, "once once of them has done it's thing then go on and do..." | |||
Typically you're probably doing something else with the rsult. | 17:40 | ||
So they're primarily useful for synchronization. rather than racing to a result like winner is good for. | |||
17:40
ssutch joined
|
|||
dalek | d: d075830 | larry++ | STD.pm6: demote winner/combine to term |
17:40 | |
17:41
kaare_ left,
fhelmberger left
|
|||
dalek | : 5f9d992 | (Tobias Leich)++ | misc/perl6advent-2013/schedule: took two slots |
17:43 | |
TimToady | I think we don't need special syntax to implement gladiation; the winning entity has sufficient information to optionally kill the losers if the losers provide a passable (pun intended) api. | ||
17:46
jnap joined
|
|||
TimToady | ESL lesson: "Elves are immortal, but passable." | 17:46 | |
17:48
darutoko left
|
|||
huf | TimToady: you'd need a very large intestine... | 17:48 | |
jnthn | We can write a timeout combinator for the simple cases too :) | 17:49 | |
TimToady revokes huf's pass. | |||
geekosaur | well, we do use double colons for objects :p | ||
TimToady | jnthn: treu | ||
huf | TimToady: so i ... i cannot pass? | ||
TimToady | I have a bridge to sell you. It's not all it's cracked up to be... | 17:50 | |
jnthn | *lol* | ||
17:50
stevan__ joined
|
|||
huf | heh :) | 17:51 | |
TimToady | you fell for it, did you? | ||
17:53
stevan_ left
17:58
jeffreykegler left
18:01
colomon left
|
|||
dalek | ast: 259ed8d | coke++ | test_summary: FIX jvm fudgespec skip |
18:01 | |
18:03
dakkar left
18:04
jeff_s2 joined
18:05
jeff_s1 left
18:09
baest left,
baest_ joined
18:10
colomon joined
18:15
mattp_ left
|
|||
FROGGS .oO( say fast "fudgespec skip, fudgespec skip, fudgespec skip, fudgespec skip, fudgespec skip" ) | 18:18 | ||
18:18
aindilis` joined,
aindilis left
|
|||
TimToady | .oO( can I just think it fast? ) |
18:18 | |
FROGGS | if you imagine saying it :o) | 18:19 | |
TimToady | I imagined saying it fast. :P | ||
timotimo | goalpost movement again, he? | 18:20 | |
eh? | |||
TimToady | just generalized the goalpost to a finish line :) | ||
diakopter | wheh | 18:21 | |
TimToady | heh, pick two. | 18:22 | |
timotimo is not sure any more what exactly he has to change | |||
if i change winner to a term, i can keep more, done and later (albeit renamed) as statement_modifier? | |||
TimToady | only winner and combine need to be terms | 18:23 | |
so we don't have to keep putting 'do' in front of them | |||
timotimo | i don't know about combine yet | 18:24 | |
what does that do? | |||
is that for combining multiple channels into one? | |||
TimToady | combinates taps rather than promises/channels | ||
timotimo | ah, ok | 18:25 | |
TimToady | and a timeout probably doesn't make sense for it, unless it does. | ||
jnthn | combine basically sets up an actor that is also tappable. | ||
TimToady | but there's no polling, so 'wait 0' makes no sense | 18:26 | |
jnthn | And that taps many other supplies | ||
18:26
mattp_ joined
|
|||
jnthn | The actor-ness needed 'cus you don't get to control when the supplies you tap throw stuff at you. | 18:26 | |
But you do want to write code without having to lock everywhere. | |||
shop & | 18:28 | ||
TimToady | channels are locking in the sense that if you exert any queing backpressure, the throwers have to stop throwing until you catch up | ||
timotimo | jnthn: do you expect me to implement combine as well until your talk? :) | ||
TimToady | it's probably easier than winner :) | ||
you don't worry about the scheduling, only composition of callbacks | 18:29 | ||
18:30
jeff_s2 left
|
|||
jnthn | timotimo: Well, it's only syntaxing the "on" that I already implemented... | 18:30 | |
I don't think it's undergone any big semantic changes. | |||
TimToady | not really, though thinking about changing tap to take one positional and two named args rather than three positionals | 18:31 | |
timotimo | i don't know what the on thing is you're talking about :P | ||
18:31
jeff_s1 joined
|
|||
timotimo | but i'll dive into my code again | 18:31 | |
TimToady | so the named args can look like they do in combine | ||
timotimo: it's just like .then on a promise, only more so :) | 18:32 | ||
timotimo | ah | ||
that doesn't seem like a syntaxing thing to me. more like a method call | |||
jnthn | TimToady: I think I'm good with the named args approach | 18:33 | |
TimToady | still not sure I want to call failure 'fail' though, since that conflicts with the builtin function | ||
jnthn | Well, I named it "fail" on purpose to say "you're shoving an exception somewhere else" | 18:34 | |
It felt strangely consistent. | |||
18:34
lizmat joined
|
|||
jnthn | really shop & | 18:35 | |
TimToady | it is, but it prevents us from ever defining winner/combine like we do class bodies: run the non-declarative statements, then take the declarations and compose something | ||
in fact, winner/combine should probably be called declarators | 18:36 | ||
ajr_ | I just noticed the update to S32, about listless map {} - is that an especially lazy form of the instruction? | 18:38 | |
timotimo | no, it's just as lazy as map 0..* {} | 18:39 | |
lizmat | map {}, 0..* actually | ||
timotimo | er, yes | ||
18:40
pecastro_ left
|
|||
lizmat | but hopefully without the overhead of an actual counter going from 0 to Inf | 18:40 | |
18:40
pecastro joined
|
|||
timotimo | yup | 18:41 | |
that wouldn't be much, but still. | |||
18:44
[Sno] left
|
|||
timotimo chased the renames and turning winner into a term | 18:44 | ||
18:44
ggoebel joined,
[Sno] joined
|
|||
TimToady is turning them into declarators now :) | 18:44 | ||
timotimo | oh, but wait needs to take an xblock now, too | ||
TimToady | yep | ||
timotimo | do declarators already exist? | ||
TimToady | hang on | ||
diakopter | all the things to declarators | 18:45 | |
timotimo | there are many proto tokens something_declarator | 18:46 | |
dalek | d: 87ac055 | larry++ | STD.pm6: add combinator_declarator |
||
timotimo | ah, indeed, there's a tokne declarator | ||
18:46
masak_ is now known as masak
|
|||
masak | oh hai, #perl6 | 18:46 | |
FROGGS | masak: \o/ | ||
diakopter | TimToady: but the marcos | 18:47 | |
timotimo | now we have catch and CATCH? | ||
diakopter | ermasak, macros | ||
masak | :P | ||
FROGGS | masak: welcome back :o) | ||
masak | thank you :) | ||
moritz | masakro! | ||
TimToady | catch is only for use inside 'combine' | ||
18:48
PZt left
|
|||
timotimo | hi masak :) | 18:48 | |
TimToady | it's better than 'fail', and since the failure comes in as $_, it might end up looking a lot like a CATCH on the inside anyway | ||
masak | "I love it when a unification comes together" | ||
timotimo | how's life? how's t4? how's that super cool trick with feeds to implement your blog in only 5 lines of code? | ||
masak | timotimo: thank you for asking. | 18:49 | |
18:49
PZt joined
|
|||
masak | timotimo: (a) life, of the kind that doesn't happen on #perl6 but happens out in Cartesian space, with other people, is catching up with me. it's great, but leads to little time for #perl6. | 18:50 | |
timotimo: (b) t4 is standing still right now. it's at the top of my list, though. | |||
timotimo: (c) that super cool trick is still alive and well. stand by. | 18:51 | ||
man, I nees to backlog. | |||
need* | |||
timotimo | sounds good, glad to hear :) | 18:52 | |
masak | how does 'done' as a combinator declarator rhyme with 'done;' as a Test.pm sub? | 18:53 | |
18:55
prevost joined
|
|||
dalek | kudo/WINNER: 5ba95a7 | (Timo Paulssen)++ | src/vm/jvm/core/asyncops.pm: a single named positional is fine for done/more, too. |
18:56 | |
kudo/WINNER: dcc8b05 | (Timo Paulssen)++ | src/ (5 files): chase lots of changes to winner: - all the statements are now in the new class "combinator_declarator" - "later" is now called "wait" and always takes a parameter. - "combine parses, but throws NYI for now. |
|||
FROGGS | tadzik: there is a panda PR | 18:59 | |
timotimo | aaaand it doesn't compile | 19:02 | |
moritz | ♪ the winner took it all ♫ | ||
lizmat | masak: I guess it will confuse the fudger a lot | ||
masak | not sure the fudger cares about 'done' | ||
19:02
rindolf left
|
|||
masak | but I was thinking, how does the Perl 6 parser distinguish? | 19:03 | |
jnthn | r: sub when() { }; when; | ||
FROGGS | you'd have to use done(), right? | ||
camelia | ( no output ) | ||
jnthn | Apparently it can there... | ||
dalek | ecs: d0fb631 | larry++ | S17-concurrency.pod: s/fail/catch/ on receiving end, tap has named args |
||
timotimo | i'm not sure why it's wrong ... | 19:04 | |
diakopter | masak: I'm afraid you'd never finish backlogging... it's grown tremendously lately | ||
TimToady is tired of collisions with Test.pm | |||
masak | "ypu'd have to use done()" sounds like a rather big change to the existing spectest suite. | ||
TimToady | just a perl -i :) | 19:05 | |
masak | and to the ecosystem in general. | ||
timotimo | why would winner $self { more * { $_ }\ndone * { last } } give TTIAR? | ||
FROGGS | masak: I didn't say that I would like or recommend it :o) | ||
masak | big breaking change. | ||
TimToady | timotimo: shouldn't, if that's parsed as a statement list | ||
jnthn | masak: I think my example of when; above working shows that this may also not cause a problem. | 19:06 | |
timotimo | i implemented winner as <sym> <xblock> and more and friends as <sym> <xblock(1)> | ||
and combinator_declarator is inside declarator | |||
masak | jnthn: indeed. | ||
r: sub when() { }; when | 19:07 | ||
camelia | ( no output ) | ||
FROGGS | rp: sub say () { say 42 }; say | ||
TimToady | it could be forced with a dynvar | ||
camelia | rakudo-parrot 75c45f: OUTPUT«===SORRY!===CHECK FAILED:Calling 'say' will never work with argument types (int) (lines 1, 1) Expected: :()» | ||
TimToady | most keywords require a space after, so done; is fine | 19:08 | |
fail "foo"; # not so much | |||
timotimo | sadly, rxtrace is immensely unhelpful | 19:09 | |
19:09
diakopter is now known as TimToTimTo
|
|||
FROGGS | hmmm, I feel like panda needs to adjust its shebang line when it installs itself (or other executables for that matter) | 19:10 | |
TimToady | std: my $self; winner $self { more * { $_ }done * { last } } | 19:11 | |
camelia | std d075830: OUTPUT«ok 00:01 125m» | ||
FROGGS | maybe it should even create panda[-p|-j] variants | ||
japhb | FROGGS: +! | ||
FROGGS: +1 | |||
FROGGS | japhb: to which statement? :o) | ||
timotimo | could it be declarator in rakudo is significantly different from the one in std? | 19:12 | |
japhb | There are some times when I want to install a module to All The Backends, but other times that I have a module that only works on a limited number of backends (and will fail tests on the others) | ||
TimToady | did you add <combinator_declarator> as an alternate in declarator? | ||
timotimo | yes | ||
FROGGS | hmmm | 19:13 | |
japhb | Also, I am also +1 to adjusting shebang lines to match the backend a script is being "compiled" for. | ||
TimToady | and added the syntax category? | ||
and didn't misspell anything? | |||
timotimo | the ... syntax category? | ||
FROGGS | japhb: well, that would introduce a problem actually | 19:14 | |
timotimo | i have a proto token if you mean that | ||
japhb_ | timotimo: See the beginning of TimToady's STD patch | ||
japhb | FROGGS, oh? | ||
FROGGS | japhb: maybe I can only solve it by S11 itself | ||
19:14
SamuraiJack left
|
|||
TimToady | timotimo: yeah, the first green bit of github.com/perl6/std/commit/87ac055582 | 19:14 | |
19:14
TimToTimTo is now known as diakopter
|
|||
timotimo | no, i did not do such a thing, i thought that was an std thing | 19:14 | |
TimToady | it's a Perl 6 thing :) | 19:15 | |
FROGGS | japhb: ahh, not sure, need to think more careful | ||
japhb | Thinking: It's dangerous. | ||
timotimo | huh, i don't see an equivalent in rakudo's grammar | ||
TimToady wonders why the lexer generator didn't complain about a missing <combinator_declarator> method... | |||
FROGGS | japhb: panda should get at least a --backends option | 19:16 | |
japhb | YES | ||
19:16
sqirrel joined
|
|||
TimToady | timotimo: it's usually called a proto rule or some such in rakudo | 19:16 | |
FROGGS | otherwise you could only install modules for your default backend | ||
timotimo | i have a proto token combinator_declarator { <...> } | 19:17 | |
lizmat | japhb: like p5, I think you should only be able to install for that version of perl you're currently running with | 19:18 | |
ggoebel | PO | 19:19 | |
japhb | lizmat: Sure, but in the current world, you can have perl6-p, perl6-j, perl6-m all in your path, and perl6 symlinked to one of them. Panda should get the same treatment. | ||
FROGGS | good point, so I#d have to: `which panda` and then `perl6-p /path/to/panda` | 19:20 | |
19:20
fhelmberger joined
|
|||
ggoebel | sorry... cat typing | 19:20 | |
diakopter | meow | ||
FROGGS | cat++ | ||
19:20
prevost left
|
|||
TimToady | duck typing, monkey typing--what's cat typing? ;) | 19:21 | |
19:21
xinming left
|
|||
TimToady | category theory, I suppose... | 19:21 | |
19:21
xinming joined
|
|||
geekosaur | cats do what they damned well please, therefore... | 19:22 | |
huf | "cat" and "ego" go well together | 19:24 | |
and if you dont pay attention to that ego, things can get "gory" | |||
so this seems to fit | |||
masak | * lizmat just realized that (+=) for atomic updates is bogus | 19:25 | |
TimToady | timotimo: do you need to insert <.end_keyword> to require the ' ' after the keyword? | ||
timotimo | oh, i may | ||
masak | lizmat: so, how about we revert 71fd6d3abb1c5b360eae4d424a342bc6a0cb03da? | ||
TimToady | otherwise you tie with <ident> | ||
lizmat | masak: no, not completely | 19:27 | |
diakopter | lizmat: you didn't reply to my question about that | 19:28 | |
timotimo | i'm still getting TTIAR | ||
diakopter | how is it bogus | ||
TimToady wonders why we don't just have a cas($var,$newvalue) function or macro | |||
diakopter | lizmat: er, I didn't see a reply | ||
timotimo | oh, i may have to remove the whitespace between <sym> and <.end_keyword> | ||
TimToady | or make it a token, yes | ||
masak | lizmat: well, it was worth a shot. | ||
lizmat | why was it worth a shot? | 19:29 | |
masak | asking for it to be reverted. | ||
timotimo | that seems to have fixed it, yay | ||
i spoke too soon | |||
masak | lizmat: oh, "why", not "what"... | ||
lizmat | but why would *you* want to have it reverted, and are ok with it staying ? | ||
why are you Dutch so suspicious? | 19:30 | ||
masak | I don't believe that there is a sane connection between set operations and (+=) | ||
PerlJam | The capitalization in S17:807 makes me think it should be ACS instead of CAS ... unless this is another one of those french things like UTC | ||
synopsebot | Link: perlcabal.org/syn/S17.html#line_807 | ||
lizmat | .oO( why do you want to know ? ) |
||
TimToady | No true Scotsman is Dutch. | ||
masak | I don't believe we should have operators for CAS things. at least not in core. | ||
diakopter | but why wouldn't the operator just do the right thing for cas variables | 19:31 | |
TimToady | so what is += supposed to return? | ||
dalek | ecs: 73f60f7 | (Elizabeth Mattijsen)++ | S17-concurrency.pod: Remove (+=) and friends cas operators |
||
lizmat | yes, "is cas" makes much more sense | 19:32 | |
TimToady | CAS is all about known absolute values, not relative values | ||
diakopter | why was the += bogus? | ||
TimToady | ^^ | ||
lizmat | because then it would handle things hopefully correctly | ||
because CAS should be hooked to a variable, not to an operation | |||
TimToady dislikes 'is cas' changing the return semantics of $var = $newvalue | |||
lizmat | you want *all* accesses to a var to be CAS, not just some | 19:33 | |
diakopter | that's not true | ||
but you do want the defaults to be cas usually | |||
jnthn | I think cas has to be about operations, not about variables... | ||
TimToady | +1 | ||
it's a very low-level operation | 19:34 | ||
there's very little point in trying to abstract it | |||
jnthn | Well, also, it's kinda transaction-y | ||
Meaning you need to know the bounds of yoru transaction. | |||
masak | I totally don't see why CAS can't just be, you know, a sub. | ||
lizmat | " is cas" bounds the transaction to updates to a single variable ? | 19:35 | |
masak | trying to *design* it to be something else, without trying it practically in Perl 6, is premature to say the least. | ||
TimToady | lizmat: what is the lifetime of that variable? what if you return it? | ||
masak | the only reason we should spec a thing like that is if we like spec that turns out wrong over time. | ||
lizmat | TimToady: I see "is cas" hanging off of the containerdescriptor, like "is default" | 19:36 | |
diakopter | masak: it can't be a sub because the compiler needs to know how to get at the variables' memory directly | ||
TimToady sentences everyone who is confused to reread en.wikipedia.org/wiki/Compare-and-swap | 19:37 | ||
masak | diakopter: that sounds like 'is rw' semantics to me. | ||
TimToady | that's why I said it might be a macro even | ||
or a built-in, I suppose I should say | |||
19:37
kurahaupo_mobile left
|
|||
jnthn | masak: I did it as a sub in the spec, fwiw | 19:37 | |
TimToady | it can certainly parse like a sub :) | ||
masak | I suppose I meant "look like a sub". it's fine if it's a built-in. | ||
diakopter | jnthn: but that sub in the spec makes no sense | 19:38 | |
jnthn | diakopter: How so? :) | ||
diakopter: I didn't put anything into S17 that I didn't already know how to implement, or already had implemented :P | |||
TimToady | diakopter: he said "something like", so it's fine :P | ||
diakopter | jnthn: I'm thinking of the one that had the + operation in it | 19:39 | |
jnthn | diakopter: cas($a, { $_ + 1) # like this? | ||
uh, but with the } | |||
diakopter | yes | 19:40 | |
how does the compiler make that cas | |||
TimToady | I don't see anything like that at S17:816 | ||
synopsebot | Link: perlcabal.org/syn/S17.html#line_816 | ||
masak | "using internals" | ||
jnthn | diakopter: It doesn't need to, given $a is a scalar container, so we operate on updating its contents. | ||
timotimo | i think it's parsing winner, then starts parsing an expression and then gets surprised by the { | ||
jnthn | diakopter: But it's just a generalization of the usual CAS pattern. | ||
timotimo | how do i make that work? | ||
diakopter | jnthn: but how does the read of the prior value work with the + | 19:41 | |
19:41
kivutar_ joined,
kivutar_ left
|
|||
diakopter | (where does it inject the atomic cpu instruction) | 19:41 | |
TimToady | timotimo: s/block/xblock/ everywhere? | ||
lizmat | I always interpreted S17:816 as pseudocode, to get the point across | 19:42 | |
synopsebot | Link: perlcabal.org/syn/S17.html#line_816 | ||
19:42
colomon left
|
|||
FROGGS | why does `time perl6-p panda` take 6.3s? | 19:42 | |
jnthn | loop { my \orig = nqp::decont($a); my \new = nqp::decont(the_block(orig)); last if cas_scalar($attr, new, orig) == orig; } | ||
timotimo | TimToady: yes, i did that | ||
TimToady | FROGGS: maybe it's calling out to perl6-j :) | ||
FROGGS | TimToady: no, that'd only need 4.7s :o( | 19:43 | |
diakopter | jnthn: okay, but that eliminates the possibility of using the increment atomic op | ||
or the add atomic op | |||
TimToady | that's a matter for the optimizer | 19:44 | |
jnthn | diakopter: Oh...then the real thing at issue is I wrote a crappy example that's better done with something else :) | ||
FROGGS | the timomizer? | ||
diakopter | jnthn: well, I'm sure it's possible to optimize to incr or add, but I can't see how yet | ||
TimToady | maybe we should switch to the CAS style that returns success or failure | 19:45 | |
19:45
woolfy joined
|
|||
TimToady | rather than doing our own comparison | 19:45 | |
jnthn | The thing about all of this is that I see cas as a *low level* thing. | 19:46 | |
TimToady | metoo | ||
if an architecture needs a different primitive, we may be talking about conditional compilation | |||
jnthn | The sugar form I suggested is just abstracting a common "read an immutable data structure, make a new one incorporating the change, and try to "commit" the reference update" pattern | ||
TimToady | but most modern architectures support CAS now | 19:47 | |
in some form or other | |||
albeit with a rather limited number of bits in some cases | 19:48 | ||
CAS on an int32 is a much different matter than CAS on an Int | |||
the latter is likely close to impossible without going toward STM | 19:49 | ||
japhb_ | ... and double-wide CAS | ||
TimToady | still limited | ||
diakopter | we have to do our own comparison on the CAS on the Int, and are updating pointers | ||
(and definitely can't do the atomic incr or add) | |||
TimToady | the transaction becomes much larger | ||
timotimo | TimToady: could there be a reason why combinator_declarator isn't the right category for something that takes an xblock? | ||
FROGGS | ahh, the slow thing is probably that it checks for the first writeable diretory and does other setup tasks | ||
lizmat | couldn't CAS just not work on an container descriptor attribute that gets incremented on every update ? | ||
japhb_ | ISTR that PowerPC has a different primitive than CAS that it prefers, but I don't recall what it is offhand. | ||
timotimo | because it doesn't seem like the xblock will terminate the <EXPR> at the right moment for a block to be acceptable | 19:50 | |
TimToady | it shouldn't be any different from an ordinary xblock in a statement list in that regard | ||
japhb_ wonders how many canon_path calls get done during panda startup | 19:51 | ||
TimToady | but maybe rakudo adds more semantics to xblock that are interfering? | ||
lue | I'm assuming compiling r-m, I should expect a bunch of "WARNING: nominal type check NYI" compiling CORE.setting, right? :) | ||
TimToady | STD is just a parser, after all | ||
timotimo | lue: yes | ||
lizmat | jnthn, diakopter: couldn't CAS just not work on an container descriptor attribute that gets incremented on every update ? | ||
diakopter | I don't know about such attributes | ||
19:52
fhelmberger left
|
|||
japhb_ | Actually FROGGS: I'd lay some odds it's either A) you're running an not-yet-installed panda, so no modules are compiled, or B) the cost of parsing the module list JSON | 19:52 | |
timotimo | TimToady: would it be terrible if i turned it into a term for the time being? because ISTR that worked | ||
19:52
kurahaupo joined
|
|||
FROGGS | japhb: it is an installed panda | 19:52 | |
19:52
fhelmberger joined
|
|||
TimToady shrugs | 19:52 | ||
lizmat | two threads update the same variable: each one checks the value of the container attribute before and after the change is completed: | ||
timotimo | i'll try that again then. | 19:53 | |
diakopter | lizmat: well the low-level cas operation returns the orig value | ||
TimToady | lizmat: you're starting to talk STM, not CAS | ||
diakopter | so it doesn't/can't check it afterwards | ||
lizmat | TimToady: perhaps, I still like STM :-) | ||
timotimo | though i think i can only change winner and combine into term and leave the others statement_control again | ||
because done, more, catch and wait wouldn't be wanted in expressions inside winner/combine blocks | 19:54 | ||
TimToady | is fine for now | ||
19:57
fhelmberger left
|
|||
diakopter | lizmat: the low-level cas operation (probably repr "method^Wsomething less inflammatory") returns the original, so that's the value that's checked to see whether it was successful | 19:59 | |
(whether it's checked within the op or not - either way) | 20:00 | ||
dalek | kudo/nom: a7ae9a9 | (Elizabeth Mattijsen)++ | docs/release_guide.pod: A friendly reminder that we have a release soon |
20:01 | |
diakopter | lizmat: oh now I see what you were suggesting with the incremented version number; that's a form of a lock | 20:02 | |
lizmat | indeed | 20:03 | |
timotimo | i can't seem to get it to work at all right now :o | ||
FROGGS | japhb: 0.6s slurping a 35kb file, 4.5s spent on from-json for that file | 20:05 | |
20:05
dwarring joined
|
|||
diakopter | jnthn: OHHH you said "reference update" | 20:05 | |
I thought we were talking about integer instructions.. didn't realize we were talking bout boxed thingsies | 20:06 | ||
jnthn | diakopter: oh! | ||
:) | |||
diakopter | jnthn: so yes, clearly no possibility for xincr or xadd there | ||
jnthn | diakopter: Yeah, I shoulda spotted the mis-understanding when you said that. Sorry. Not at my sharpest today... | 20:07 | |
20:07
sqirrel left
|
|||
japhb | FROGGS, yeah, both of those numbers are horrid. | 20:07 | |
That's why github.com/japhb/perl6-bench/blob/...parse-json | |||
diakopter | jnthn: however, my question then is about primitive vars.. how to use the special syntax to do atomic incr/add | 20:08 | |
jnthn | diakopter: Yeah, I didn't try to attach either of those. :) | ||
diakopter | attach? | 20:09 | |
attack? | |||
jnthn | uh, attack | 20:10 | |
wtf :) | |||
diakopter | i like trainses | ||
lizmat | .oO( until your car detaches ) |
||
FROGGS | japhb: I see | ||
diakopter | lizmat: it's an allusion to the asdfmovie 1-6 where the kid who likes trains get smushed by trains often | 20:11 | |
lizmat | fortunately we only get smashed | ||
by trains of thought here | |||
masak is on a train | |||
20:12
dave1c_ joined
|
|||
timotimo | wtf is this i don't even | 20:12 | |
lizmat | get cut short ? | 20:13 | |
20:13
iSlug left
|
|||
timotimo tries putting the rules someplace else | 20:13 | ||
dalek | d: 8370f3f | larry++ | STD.pm6: undo 87ac0555827223eec4da40c72dfeab90b996f525 |
||
20:14
dave1c left
|
|||
timotimo | oh | 20:14 | |
did my plight inspire pity in you? | |||
masak | TimToady: when you undo commits, do you perchance use `git revert`? | 20:15 | |
20:16
xenoterracide joined
20:17
kurahaupo left
|
|||
timotimo | i made it work >_< | 20:18 | |
it was about a missing <.ws> | |||
i'm such a derp sometimes. | |||
lizmat | r: (1).map: start {...} # strange failure in the bowels of reification | ||
camelia | rakudo-parrot 75c45f: OUTPUT«===SORRY!=== Error while compiling /tmp/lvCNQE7oslUndeclared routine: start used at line 1. Did you mean '&spurt', '&sqrt', '&sort'?» | ||
..rakudo-jvm 75c45f: OUTPUT«Unhandled exception: Method 'count' not found for invocant of class 'Promise' in (gen/jvm/CORE.setting:7210) in reify (gen/jvm/CORE.setting) in (gen/jvm/CORE.setting:7122) in reify (gen/jvm/CORE.setting) in gimme (gen/jvm/CORE.setting:…» | |||
timotimo | r: (1).map: do start {...} | 20:19 | |
camelia | rakudo-jvm 75c45f: OUTPUT«Unhandled exception: Method 'count' not found for invocant of class 'Promise' in (gen/jvm/CORE.setting:7210) in reify (gen/jvm/CORE.setting) in (gen/jvm/CORE.setting:7122) in reify (gen/jvm/CORE.setting) in gimme (gen/jvm/CORE.setting:…» | ||
..rakudo-parrot 75c45f: OUTPUT«===SORRY!=== Error while compiling /tmp/tvuzJQIX9yUndeclared routine: start used at line 1. Did you mean '&spurt', '&sqrt', '&sort'?» | |||
lizmat | it's a runtime error, it compiles ok | ||
timotimo | ah | 20:20 | |
i see that now | |||
20:20
spider-mario joined
|
|||
jnthn | lizmat: It's the same as if you pass map anything that's not a block. | 20:21 | |
I'm surprised it lets you pass a non-callable at all.. | |||
lizmat | argh | ||
of course | |||
timotimo | oh duh :D | 20:22 | |
i'm not the only derp around today | |||
jnthn | We can all derp together! | ||
lizmat | j: my $seen; await( (1..3).map: { start { $seen++ for ^1000 }}); say $seen | 20:23 | |
camelia | rakudo-jvm 75c45f: OUTPUT«1379» | ||
timotimo | depr yourself together, man! | ||
lizmat | j: my $seen; await( (1..3).map: { start { $seen++ for ^1000 }}); say $seen | ||
camelia | rakudo-jvm 75c45f: OUTPUT«3000» | ||
lizmat | j: my $seen; await( (1..3).map: { start { $seen++ for ^1000 }}); say $seen | ||
camelia | rakudo-jvm 75c45f: OUTPUT«2663» | ||
lizmat | j: my $seen; await( (1..3).map: { start { $seen++ for ^1000 }}); say $seen | ||
camelia | rakudo-jvm 75c45f: OUTPUT«3000» | ||
lizmat | this worries me | ||
timotimo | your point being? :) | ||
lizmat | j: my $seen; await( (1..3).map: { start { $seen++ for ^1000 }}); say $seen | ||
camelia | rakudo-jvm 75c45f: OUTPUT«1792» | ||
jnthn | lizmat: *sigh* | ||
Yes, I know I owe you a blog post on why. | 20:24 | ||
lizmat | I want to be able to say something about $seen to have it always be 3000 | ||
timotimo | by putting winner and combine as combinator_declarators, i get Unexpected block in infix position again! | ||
whyyyyyyy~ | |||
it worked so flawlessly as statement_control :( | 20:25 | ||
Util | #ps in 5m | ||
timotimo | parsings are hard :( | 20:26 | |
lizmat | jnthn: I think I know why, but I'd like to see that blog post anyway | ||
timotimo | it would be cool if target=parse could dump the innermost $/ before an error is thrown | 20:27 | |
lizmat | it's just that I'm *very* worried we wind up in Perl 5.005 threads land :-( | ||
20:28
colomon joined
|
|||
timotimo | lizmat: parallelism in perl6 relies on composable thingies, which i don't think shared state counts as | 20:33 | |
lizmat | $seen++ seems pretty composable to me | 20:34 | |
but really, this is about perception and previous experiences | |||
people will come to Perl6 and see promises, and start to use them like above | 20:35 | ||
and things will not always work | |||
and won't generate any errors either | |||
timotimo | hrm | 20:36 | |
TimToady | why shouldn't reference to an unprotected external lexical cause an error? | ||
timotimo | i'd say you could use a KeyReducer for this case :P | ||
lizmat | it should! | ||
timotimo | because that's totally composable :) | ||
lizmat | but it doesn't | ||
TimToady | I've said many times that lexicals outside of threads should have extra constraints | 20:37 | |
timotimo | that's acceptable. | ||
lizmat | outside of threads? | ||
TimToady | and that's the main reason almost everything is lexical in the first place, to automatically get thread-local storage for any internal lexicals | ||
lizmat | so, every container remembers in which thread they're made | 20:38 | |
and if they're changed from another thread, they should bomb? | |||
TimToady | various semantic approaches are possible, once we notice the problem | 20:39 | |
timotimo | how do we notice if the user protected the lexicals with some locking scheme that we can't immediately see? | ||
TimToady | we can force them to declare it so | ||
jnthn | The challenge is distinguishing the cases we do want to allow it, like in combine, because we know that is safe. | 20:40 | |
timotimo | my $foo is protected_by($lock)? | ||
jnthn | otoh, that's syntactic now :) | 20:41 | |
TimToady is inclined to make outside lexicals simply not visible to the inside of a start | |||
diakopter | TimToady: but what about all the other lvalues, like array and hash slots | ||
TimToady | s/lexicals/variables/ | ||
TimToady still likes single-owner semantics too | 20:42 | ||
but I recognize it's fraught | |||
diakopter | -_- | ||
lizmat | hmmm.... so a thread/promise starts with a fresh lexical stack | ||
diakopter | but closures are essential in many cases.. | 20:43 | |
TimToady | well, or just skips to SETTING | ||
lizmat | indeed | ||
skip to SETTING | |||
TimToady | for variables | ||
it's just an idea | |||
lizmat | I guess that would stop all of the accidental accesses | ||
I like the idea | |||
diakopter | okay, but you can still pass a closure value to one of these blocks and it'll still have access to its lexical scope | ||
lizmat | it forces people to think about cocurrency | ||
yes, you still can | 20:44 | ||
TimToady | anyway, I'm certainly not against imposing some kind of discipline on outer shared state | ||
dalek | kudo/WINNER: 7213c53 | (Timo Paulssen)++ | src/Perl6/ (2 files): the previous attempt was intent on TTIAR'ing :( |
||
kudo/nom: b774722 | moritz++ | docs/ChangeLog: [doc] extend ChangeLog a bit |
|||
lizmat | I wonder whether also keeping the creation thread ID with each container | 20:45 | |
timotimo | yay, a thing i made got mentioned in the changelog \o/ | ||
lizmat | and checking that on update, wouldn't fix the closure issue | ||
jnthn | Maybe it's more about scope ownership. | ||
"Who created the invocation record" | |||
lizmat | but scopes can leak, so we need to have something to catch that | ||
TimToady doubts there is a perfect solution (outside of making everything immutable) | 20:46 | ||
but we can certainly decrease the likelihood of erroneous code | |||
moritz | and making everything immutable isn't a perfect solution either :-) | ||
lizmat | indeed, that is my main concern: code that doesn't complain, works ok most of the time, until we get a load on the system | 20:47 | |
jnthn | lizmat: That's kinda what I was trying to address. If a lookup in the thread running something crosses into a invocation record created by another thread to do a lookup... | ||
TimToady | we can at least complain bitterly if we notice such a thing happening | 20:48 | |
lizmat | but wouldn't you need to be able to do that at container level, because of closures ? | ||
masak | invocation records feel like exactly the right level for closures. | 20:49 | |
jnthn | lizmat: Closures are what I'm (badly :)) trying to address too. When you take a closure, it has an outer frame pointer. If we access soemthing that was closed over, then the lookup is crossing from an invocation record created by the thread (when the closure was invoked) to the outer one created by the original thread. | 20:50 | |
TimToady | the important thing about these shared things is not that they're shared, but that they're not transactional | ||
jnthn | In generaly, my worry about making things like the "$a++" example just work is that as soon as it does, people will then start to write The Next Idiom | 20:51 | |
for 1..4 { start while @foo { @foo.pop } } # race condition! | |||
lizmat | indeed | ||
and we need to fail that before it starts | 20:52 | ||
diakopter | why!??!!? | ||
jnthn | And the problem here is that it's not obvious where the transaction starts/ends. | ||
diakopter | how is that a race condition? | ||
(why does the user always need to care about the order of popping) | |||
lizmat | because you would be getting the same value from the array twice or not | ||
jnthn | diakopter: It's not about order | ||
diakopter | what?!?! | 20:53 | |
jnthn | No, it's not about that either. Let's suppose pop is atomic. | ||
lizmat | (it's not currently, afaik) | ||
jnthn | It's still a race because @pop boolifies @foo to tell you if there's anything more | ||
lizmat | but let's assume :-) | ||
jnthn | Then next you try to pop | ||
But somebody else might have beat you to pop the last thing. | |||
TimToady | iow, it doesn't compose | ||
jnthn | That's why things like the .Net concurrent collections don't have a Pop method | ||
They have a TryPop | |||
diakopter | that's simply solved by adding a try | ||
yeah, that | 20:54 | ||
jnthn | I guess this is all a "forgiveness > permission" thing :) | ||
In cncurrent situations you can't ask if you can, then do it, 'cus the answer may change underneath you. | |||
TimToady | well, and making it likelier that they'll pick the composable primitives over the non-composable | ||
diakopter | so why can't the while's block have a try | ||
TimToady | we're starting to talk about STM again, here, basically--keep trying to do "this" until we succeed | 20:55 | |
STM just has a funny way of defining "this" | |||
diakopter | it's not talking about STM | 20:56 | |
jnthn | diakopter: My point wasn't that you can't find *some* way to fix these, though "just add a try" works in this case provided you only catch the appropriate kind of exception. | ||
diakopter: My point was that there's not a *general* approach. | |||
diakopter | why would you need a general approach | 20:57 | |
TimToady | generality is generally...er...more general | ||
jnthn | Because solving these problems case by case is *far too hard* for the typical programmer. | ||
Which is why .Net folks are pushed away from threads/locks and towards Tasks/TPL/Rx etc, for example. | 20:58 | ||
Which all revolve around breaking problems into manageable pieces and making synchronization happen in well-defined places. | 20:59 | ||
lizmat | and threads are currently wide open on Perl6 | ||
indeed | |||
jnthn | lizmat: They are in Java and C# too, fwiw. | ||
lizmat | but Perl6 should be better | ||
TimToady | threads are sort of the Ur-DIHWIDT | ||
jnthn | lizmat: Not arguing that we should follow that. Just saying that it's a situation in languages where people actually do use threads day to day. | ||
lizmat | experienced people | 21:00 | |
jnthn | No, most of them aren't, and most of them screw it up. | ||
lizmat | well, there you go | ||
I don't want them to screw up, I want them to be steered into a direction that will do what they want | 21:01 | ||
just maybe not in the way they originally thought | |||
jnthn | Me too, which is why I've been pushing the whole promise/channel/supply thing. | ||
lizmat | and compile/runtime errors should lead them that way | ||
diakopter | adding checks for thread parity everywhere can't be the right solution | ||
jnthn | It's just that I've been focused on the carrot (hey look, nice primitive) | ||
And now we're discussing the stick. :) | |||
diakopter: Can't be as in, we can't afford to slow everything down with those? | 21:03 | ||
diakopter | yes, but it also feels wrong just because it's checks the user has to imagine | ||
lizmat | so each scope gets a thread ID ? | ||
jnthn | diakopter: If so, I agree, but iiuc what TimToady is saying, the point of having things lexical is that we can know a lot of places we don't need to do any of this. | ||
TimToady | it's just tilting the playing field, not necessarily blowing up the other guy's goal | 21:04 | |
jnthn | lizmat: fwiw, that already implicitly happens on both Moar and JVM, in that the scope gets a ThreadContext attached :) | ||
21:05
kurahaupo joined
|
|||
TimToady | if we can detect hazardous sharing 50% of the time and slap the user's wrist, they'll tend to migrate over to the safer constructs, even if it's not perfect | 21:05 | |
since perfect usually implies 'unusably slow' | |||
diakopter | jnthn: I don't know what was meant by "having things lexical" | ||
TimToady | this is in contrast to P5 where way too many vars are package/global | 21:06 | |
it's the main motivation for making $*FOO work via search rather than "local $foo" as it is in P5 | 21:07 | ||
jnthn | diakopter: I mean that a lot of variable accesses, you can look between where the variable is mentioned and where it's declared and determine statically that it's impossible that access could be on a different thread, even accounting for closure semantics. | ||
21:07
hummeleB1 left
|
|||
diakopter | alright, that optimizes for the single-threaded case | 21:08 | |
lizmat | my $seen; await( (1..3).map: { start { $seen++ for ^1000 }}); say $seen # could be caught at compile time | ||
diakopter | but what about when the user wants to parallelize things with shared data strutures | ||
TimToady | most single threads are single threaded :) | ||
lizmat | they're very singular about that :-) | 21:09 | |
TimToady | we slap their wrists when we notice them using non-sharable data structures for that | ||
diakopter | lizmat: what would be caught there | ||
what's the problem with that | |||
21:10
sqirrel joined
|
|||
TimToady | what's the problem with what? | 21:10 | |
jnthn | diakopter: Then the onus is on them to (a) say they're doing so, and (b) be extremely careful, just like you have to be in every other languages where you mutate data structures from multiple threads. | ||
diakopter | what's the problem with liz's example | ||
jnthn | diakopter: That's a "hard thing possible" rather than an "easy thing easy". | ||
diakopter | I don't understand why making all the changes atomic doesn't solve it | 21:11 | |
er, thread-safe. | |||
b/c if it's just "when you're popping from multiple threads, you need to handle for when pop fails" how is that a problem | 21:13 | ||
a problem for the user to remember/handle, I mean | |||
TimToady | "all the changes" is transaction scoping, and users tend to think in transactions that are not atomic unless we warn them off of it where we can | ||
pragmatically, we admit the possibility of DIHWIDT, but we also vaccinate people and treat them when their sick | 21:14 | ||
dealing with users is sometimes more like being a doctor than like being a starship engineer :) | 21:15 | ||
so we need to say "Well then, don't do that." a little more often than we like | 21:16 | ||
diakopter | I don't see how you can ever possibly detect that | ||
TimToady | you can detect some of it | ||
diakopter | with any reliability | ||
does anyone know what's the problem with liz' example? | 21:17 | ||
jnthn | On "what can be detected", it may serve us well to look at things like TSAN, Go's race detector, etc. | ||
lizmat | some is already good | ||
jnthn | It's not like we're the first people looking at this problem. | ||
lizmat | in any case, I think we need to make sure that multi-thread access to hashes, need to be protected | ||
diakopter | I feel like we're not looking at the problem; we're launching nuclear missles at it from 3 feet away | 21:18 | |
lizmat | we don't want that to be able to corrupt a hash | ||
hhe | |||
diakopter | that was never at issue | ||
lizmat | ok, I'll go stand a little further away | ||
TimToady | "I see you've used a single-threaded implemented of Scalar for variable $seen there, and referred to it from inside a thread. Howsabout you declare it 'my $seen is threadsafe' to get a Scalar with atomic increment at line 42" | ||
lizmat | which was "is cas" was all about | ||
TimToady | cas is the wrong name for that | 21:19 | |
lizmat | granted | ||
it defines the implementation | |||
"is safe" maybe better ? | |||
TimToady | well, that's a bit too general :) | 21:20 | |
diakopter | I don't understand what happened to the auto-upgrading threadsafe containers we've talked about in moar for ages (and that can be similarly done on jvm) | 21:21 | |
TimToady | but I could see requiring a user to declare a lock-free hash implementation is to be used for a shared hash, or an array that doesn't support pop | ||
jnthn | "is cafe" :P | ||
TimToady | diakopter: if we can do that, great | ||
diakopter | when was there ever a question we could do that | ||
I thought that was the plan | |||
TimToady | but it doesn't solve the boolean vs pop issue necessarily, from a transactional point of view, if you still support pop | 21:22 | |
the whole problem with transactions is that they are not reductionistic | |||
just because all the operations are atomic doesn't make the composed operation atomic | 21:23 | ||
jnthn | diakopter: That aspect solves the VM safety level problems, for certain, but the issues is...what TimToady just put better than I was going to. | ||
TimToady | so lock-free structures are a good start | ||
jnthn | diakopter: If your problem involves anything more than that single data structure, you're still left with a problem. | ||
diakopter | jnthn: I think I was trying to express earlier that since you can't solve the general case (or come anywhere close, from what I can see), it seems trying to warn in particular other cases will just be confusing | 21:24 | |
because you can't warn on the passing closures as parameters | |||
or lexicals | |||
or container slot values | 21:25 | ||
TimToady | all-or-nothing is not PerlThink | ||
jnthn | Lock free data structures are really useful *if* your problem reduces to things that they can do atomically, which sometimes hapens. A Channel is basically a lock free queue. | ||
diakopter | or-anywhere-close | ||
TimToady | well, you can block on backpressure, and have a cyle of that, which is a kind of deadlock | ||
jnthn | True | 21:26 | |
21:26
beastd joined
|
|||
timotimo considers commuting home again | 21:27 | ||
yup, i'll do that. | |||
TimToady | sounds like a complicated transaction :) | ||
diakopter | jnthn: "you're still left with a problem" - no one has explained the problem except "I don't want to have to teach people to handle a failed pop, or I don't want pop to ever fail" | 21:28 | |
jnthn | diakopter: At this point I fear if I showed you 10 more cases where the race isn't immediately obvious, then we found a way to fix it, you'd still be telling me the same thing. :/ | 21:29 | |
Even though the fixes would likely be different each time. | 21:30 | ||
lizmat | Niederrhein about to wrap up, decommuting soon | ||
diakopter | I don't think it's a valid worry; I haven't understood the way to fix the first one yet | ||
I'm confused by various peoples' descriptions of what they're imagining/proposing because they all seem conflicting | 21:31 | ||
it's like, let's all throw word soup on the wall and see what sticks | 21:32 | ||
also, Wall | |||
TimToady | the basic problem is threefold: 1) nobody understands how to scale up transactions, and 2) an all-or-nothing approach is doomed to fail, and 3) nobody is happy with a partial solution, but that's what we're *guaranteed* to end up with, so how can we best push the user toward enlightement? | 21:33 | |
lizmat | well, I think it's better than everybody being silent and ignoring the concurrent elephant in the room | 21:34 | |
diakopter | no one has answered why "+= | ||
"+= is bogus" | 21:35 | ||
TimToady | it's fine, but I wouldn't call it CAS, is all | ||
diakopter | since jnthn seemed to reply that it should be on the operations, not variables | ||
TimToady | he was talking specifically about CAS I believe | ||
not about how to make += safe | 21:36 | ||
s/safe/atomic/ | |||
jnthn | Yes, I was talking about CAS on the operations not variables thing. | ||
TimToady | the S stands for Swap, darn it, not increment :) | ||
diakopter | okay, I was asking about the primitive case again | 21:37 | |
TimToady | asking what? | ||
diakopter | (afaict there can be an atomic += for primitives) | ||
lizmat | for natives you mean? | 21:39 | |
TimToady was just questioning how you signal failure on that | |||
diakopter | yes | ||
lizmat | int instead of Int | ||
diakopter | atomic add or incr can't possibly fail | ||
it always succeeds | |||
that's the benefit | 21:40 | ||
21:40
sqirrel left
|
|||
TimToady | but that's not how CAS works, hence the confusion | 21:40 | |
jnthn | Depends what hardware you have, mind...if it doesn't support doing that, then it'll have to be implemented out of something like CAS that can fail. | ||
And then emulate the "not fail" by retrying. | |||
TimToady | which goes back to what I said about conditional compilation | ||
different arches have different primitives | |||
alas | 21:41 | ||
at some point it becomes less meaningful to talk about "primitives" and just talk about atomicity and/or transaction safety | |||
21:42
kurahaupo is now known as kurahaupo2
|
|||
TimToady | and there's a bumpy transition from atomic to transactional, if atomic always succeeds, but a transaction has to be rollbackable | 21:43 | |
atomic doesn't imply commit/rollback semantics | |||
21:44
lizmat left,
lizmat joined
|
|||
TimToady | but all the the approaches I've seen to composing transactions involve either the possibility of deadlock/livelock, or the ability to just keep hammering on it till you get a commit to go through, à la STM | 21:45 | |
but even STM doesn't scale to disk or database transactions | |||
21:47
stevan__ left,
eternaleye left
|
|||
TimToady | and if you compose transactions inside transactions, you find yourself in the odd position of having to rollback inner transactions that have been "committed" | 21:48 | |
21:48
[Sno] left
21:49
eternaleye joined
|
|||
lizmat | decommiute& | 21:49 | |
21:49
lizmat left
21:50
woolfy left
|
|||
masak | clearly the inner transactions need to have only been "speculatively committed" until the outer transaction is truly committed. | 21:50 | |
TimToady | .oO(The all-or-nothing never works out well because, while we all understand 'nothing' pretty well, nobody understands 'all'...) |
||
*approach | |||
masak: which means there can never be final commitment without someone say "That's all, folks!" | 21:51 | ||
*saying | 21:52 | ||
masak | well, there can be an outermost transaction. | ||
diakopter | masak: I can only hope you're tongue-in-cheek there | ||
TimToady | gah, can't type to keep up with my brane today, gotta start thinking slower... | ||
masak: the question is, who's to be master, that's all. | 21:53 | ||
diakopter | the outerost transaction is the big bang | ||
masak | diakopter: no, it would be wise to assume ignorance rather than irony in my case right now. | ||
21:53
spider-mario left
|
|||
masak | I seldom include the "big bang" abstraction in my programs. | 21:53 | |
TimToady | diakopter: how do you know that's the outer one? | ||
diakopter | in that time dimension anyway.. | 21:54 | |
masak | and yet they commit to things. | ||
& | |||
TimToady | Maybe our entire universe is answering a what-if question, and once we get a result of 42, we're good to go. :) | 21:56 | |
21:57
rurban1 left
21:59
colomon left
|
|||
TimToady | Maybe our universe is being evaluated lazily, and we'll never actually get to the Big Rip, or Bound, or Whimper, because nobody will ask for the result... | 21:59 | |
*Bounce | |||
21:59
rjbs joined
|
|||
rjbs | Whoops, I didn't rejoin after my screen-to-tmux conversion! | 21:59 | |
diakopter | rjbs: HOW CUTE ARE YOU | ||
nwc10 | rjbs: you took the plunge? | 22:00 | |
rjbs | nwc10: Yes, a bit over a week now. | ||
nwc10 | not that I have the font for it locally, but I think my irssi is now not being stupid so I can send 🐫 | ||
rjbs | Yes, tmux let me do that again, too. 🐫 | 22:01 | |
22:02
stevan_ joined
|
|||
TimToady | shouldn't that be 🐪 | 22:03 | |
22:07
dmol left
22:09
dmol joined
22:27
[Sno] joined
|
|||
dalek | nda: 8375930 | (Tobias Leich)++ | / (2 files): use $*EXECUTABLE_NAME instead of hard-coded 'perl6' Because we now have perl6-p and perl6-j binaries. |
22:30 | |
nda: 41a73f3 | tadzik++ | / (2 files): Merge pull request #60 from FROGGS/master use $*EXECUTABLE_NAME instead of hard-coded 'perl6' |
|||
tadzik | FROGGS: thanks! | ||
FROGGS | tadzik: pleasure :o) | 22:31 | |
lue | preflex list | 22:35 | |
preflex | Botsnack: [botsnack]; Cdecl: [cdecl]; 8ball: [8ball]; excuses: [excuse]; Factoid: [+, -, ., ?, delete, get, store]; Help: [help, list]; Karma: [++, --, karma, karmabot, karmatop]; Nickometer: [nickometer]; Nickr: [nickr]; PlokiRE: [re]; Seen: [seen]; Sixst: [6st, ordinal]; Tell: [ask, clear-messages, messages, tell]; Rot13: [rot13]; Quote: [be, quote, remember]; WCalc: [calc, wcalc]; Version: | ||
[version]; XSeen: [xseen]; ZCode: [zdec, zenc] | |||
22:36
dmol left
22:38
dmol joined
22:39
PacoAir left
22:45
stevan_ left
22:54
dmol left
22:59
BenGoldberg joined
23:01
colomon joined
23:02
arnsholt_ joined
23:03
arnsholt left
23:08
stevan_ joined
23:13
beastd left
23:22
btyler left
23:23
jnap left,
bluescreen10 left
|
|||
japhb_ | Is there a Perl 6-standard (as opposed to Rakudo-specific) way to refer to the argument capture of a routine that does not specifically specify a capture in the signature? My immediate use case is being able to refer to the arguments of MAIN as a unit, instead of a bunch of named args (which the auto-USAGE code wants to see) | 23:24 | |
23:36
lizmat joined
|
|||
jnthn | japhb_: Is there a reason not to specify a capture in the siggy? | 23:39 | |
Noting that you can do it *and* then write a normal signature too... | |||
I'm not aware of a way besides that, though... | 23:40 | ||
And I'd somewhat rather we keep it in the signature | |||
As it's easy to detect if we have to build it. | 23:41 | ||
And a raft of the opts I've got coming up to better use invokedynamic probably rely on knowing this... | |||
japhb_ | Ah, interesting, that's a really good data point. | ||
23:42
woolfy joined
|
|||
japhb_ | In that case, I guess the best option is to teach the USAGE generator to ignore the capture. | 23:42 | |
23:46
ajr_ left
23:55
PZt left
|