|
svn switch --relocate svn.openfoundry.org/pugs svn.pugscode.org/pugs/ | run.pugscode.org | spec.pugscode.org | paste: sial.org/pbot/perl6 | pugs.blogs.com Set by avar on 16 November 2006. |
|||
|
00:13
weinig is now known as weinig|food
00:42
weinig|food is now known as weinig
|
|||
| TimToady | fg | 00:57 | |
| oops :) | |||
| well, as long as I'm here, anyone have any opinions on the floor vs euclidian divmod debate? | 00:58 | ||
| allbery_b has no horse in that race, but notes that Haskell provides both (divMod and quotRem) | 01:00 | ||
|
01:02
b00t joined
01:16
bcorn joined,
theorbtwo joined
01:28
davidm123 joined
01:44
hexmode joined
02:02
bucky joined
02:03
hexmode joined
02:05
diotalevi left
02:09
hexmode joined
02:13
autark joined
02:47
demy joined,
demy left
02:49
asey joined,
theorbtwo joined
02:51
weinig is now known as weinig|zZz
|
|||
| dduncan | TimToady, regarding your question, the only opinions I have in that regard at the moment is that Int/Int should result in an Int result, Num/Num should be num, and those 2 operators should perhaps look different so that users can easily tell what is going on | 02:52 | |
| TimToady | Int/Int --> Int doesn't avoid Least Surprise for most people. | 02:54 | |
| most people will expect Int/Int --> Num because that's how math works | 02:55 | ||
| SamB | yeah. except broken people! | ||
| TimToady | well, grade school math... | ||
| however, separating out different operators will probably be okay | 02:56 | ||
| SamB | well, maybe in elementary school, the answer has to be an integer too, but you never run into any problems where that doesn't happen? | ||
|
02:57
finchely joined,
mako132_ joined
|
|||
| TimToady | true, they teach remainders before they teach fractions... | 02:57 | |
| well, gotta decommute & | 02:58 | ||
| davidm123 | getting this very same problem in building perl6 under cygwin..aspn.activestate.com/ASPN/Mail/Mess...ls/3364906 . I patched _LIB_VERSION', but miniparrot fails | 02:59 | |
| (correction: parrot not perl6) | |||
|
03:01
Psyche^ joined
03:13
Psyche^ is now known as Patterner
03:22
mako132_ joined,
mbradley joined
03:23
justatheory joined
03:25
GabrielVieira joined
03:35
asey joined
03:39
demy joined,
demy left
03:43
demy joined,
demy left
03:55
frankg joined
03:58
johnjra joined
03:59
b00t joined
04:13
nipra joined,
leed joined
04:47
lyokato joined
04:49
mjk joined
05:33
jdv79 left,
sunnavy joined
05:37
nperez joined
06:15
BooK_ joined
07:00
nipra_ joined
07:04
TimToady_ joined
07:09
bsb left
07:19
dem2 joined
07:20
dem2 left
|
|||
| Juerd | feather users: | 07:33 | |
| 2007-01-10 | |||
| Please clean up your home directory, as we're running out of storage | |||
| space on the machine that hosts the data backups. If you could remove that 6 | |||
| months old Pugs or GHC tree that you no longer touch anyway, that would be | |||
| great. Maybe there are things that you can gzip? | |||
|
07:36
dduncan left
07:41
iblechbot joined
07:44
Aankhen`` joined
|
|||
| gaal | Juerd: done (cleared O(128MB)) | 07:46 | |
|
07:49
marmic joined
07:53
dduncan joined
07:55
Southen joined
08:03
deq` joined
08:12
sunnavy joined
08:23
mj41_ joined
08:24
lisppaste3 joined
08:25
nipra_ is now known as nipra
08:36
devogon joined
08:58
elmex joined
09:08
buetow joined
09:14
andara joined
10:08
chris2 joined
10:18
fglock joined
|
|||
| fglock | audreyt: would you send me the graffle file for pugs.blogs.com/photos/visiolization...strap.html - I'll draw one for kp6 | 10:27 | |
|
10:28
ruoso joined
|
|||
| gaal | parser combinators in smalltalk: gbracha.blogspot.com/2007/01/parser...ators.html | 10:32 | |
| fglock | why does 'combinator' mean? | 10:35 | |
| what | 10:38 | ||
|
10:38
andara left
|
|||
| fglock | ah, the article defines it | 10:43 | |
|
10:45
yves joined
10:46
seano joined
|
|||
| svnbot6 | r15022 | fglock++ | kp6 - added ast transformation engine to spec | 10:50 | |
|
10:52
andara joined
|
|||
| audreyt | fglock: perlcabal.org/~audreyt/tmp/lrep.graffle | 11:00 | |
| rgs | hi audreyt | ||
| audreyt | greetings rgs | ||
| rgs | so you're going to be in Nice starting next week-end ? | ||
| audreyt | yes | ||
| and stay till the next | |||
| are you going to be present on the 2nd weekend as planned? | |||
| rgs | no, but I think I can make it on monday and tuesday | 11:01 | |
| 15, 16 (before the conference iirc) | |||
| audreyt | ack | ||
| my talk is 17th though | |||
| that means I better finish slides before you arrive | |||
| otherwise you'll find me in JIT mode :) | |||
| rgs | I'll let you know | 11:02 | |
| BTW, I just resigned from $work, so things are a bit difficult to plan | |||
| audreyt | ah. | ||
| svnbot6 | r15023 | fglock++ | mp6 - finished ast-traversal module | ||
| audreyt | are you going to be in.tw? | ||
| rgs | for OSDC ? no | 11:04 | |
| audreyt | k | ||
|
11:05
sunnavy_ joined
|
|||
| andara | hi audreyt! I'm going to Nice too. Looking forward to your talk | 11:05 | |
| audreyt | so are your place close to the conf hotel (Plaza)? is that plan that we hack at hotel? | ||
| andara: me too, I havn't started thinking about my talk | |||
| so I also look forward to it | |||
| ;) | |||
| rgs looks up plaza hotel | |||
| andara | audreyt: cool. BTW, could you please point run.pugscode.org to feather.perl6.nl:8080/runpugs/ ? | 11:06 | |
| audreyt | andara: sure, will do so now | ||
| rgs | it's very close | ||
| nice is a small city | |||
| audreyt | cool | 11:07 | |
| andara | audreyt: great, thanks! | ||
| rgs | www.flickr.com/photos/rgarciasuarez74/225906267/ <- my place, an old building which is now an historical monument | 11:08 | |
| audreyt | ...wow :) | 11:09 | |
| so I arrive at 13th and will start working on slides upon landing | 11:10 | ||
| there are conferences too at 15th and 16th | 11:11 | ||
| but I'd like to drop by and visit and hack w/ you at timeslots convenient to you, if that's okay | |||
| otherwise you can come to the hotel too :) | |||
| rgs | I'll have nothing else to do | ||
| gaal | audreyt: moose | 11:12 | |
| audreyt | gaal: antlr | ||
| gaal | fglock: a function that manipulates functions | ||
| audreyt: so i had a question about caching compilations | |||
| can't persistently memoize parseProgram because what to do with the env? | |||
| audreyt | each parseProgram theoretically gets the same clean env | 11:13 | |
| gaal | not the case today, I tihnk | ||
| audreyt | no, not at all | ||
| unless you count Test.pm.yml | |||
| we have preliminary "linking" technology | |||
| but it's not the case for normal "use" resolution | |||
| which is of course wrong... | 11:14 | ||
| gaal | so opEval should by rights first construct a clean env, parse onto it, and merge the result to the current env? that will give us a momoization point | ||
| audreyt | exactly so | 11:15 | |
| aka standard linking | |||
| gaal | ok; so in fact Env param should be dropped from parseProgram to ensure this | ||
| audreyt | exactly so. | ||
| gaal | cool | ||
| and mergePads or unionPads (i forget the name) can be wrapped in a reusable new "link" function | 11:17 | ||
| audreyt | yup. | ||
| we already do that for .pm.yml loading | |||
| what we need to do is to convince "use" to always go thru that route | |||
| but not neccessarily with .yml | 11:18 | ||
|
11:18
TimToady joined
|
|||
| audreyt | i.e. the .yml part can wait until the merge env thing works | 11:18 | |
| gaal | if we hook into opEval it'll always happen | ||
| audreyt | then we worry about proper deserialization | ||
| aye aye. | |||
| gaal | great, i'll resume this after work then | 11:19 | |
| audreyt | cool | 11:25 | |
| I need to catch some sleep... bbl | |||
|
11:34
fglock joined
|
|||
| fglock | audreyt, gaal: thanks | 11:35 | |
|
11:35
buetow joined
11:41
seano joined
|
|||
| svnbot6 | r15024 | fglock++ | kp6 - rename 'Visitor.pm' to 'Traverse.pm' | 11:45 | |
| pasteling | "evalbot_r15023" at 194.145.200.126 pasted "Pugs build failure" (375 lines, 20.9K) at sial.org/pbot/22252 | 11:51 | |
|
11:54
andara joined
11:56
xpika joined
|
|||
| svnbot6 | r15025 | fglock++ | kp6 - added proof-of-concept traverse script | 12:00 | |
|
12:03
iblechbot joined
|
|||
| fglock | ?eval my $s=''; for 1..3 { $s ~= $_; eval ' LEAVE { $s ~= 42 } ' }; $s | 12:27 | |
| evalbot_r15025 | \"123" | ||
| fglock | ?eval my $s=''; for 1..3 { $s ~= $_; LEAVE { $s ~= 42 } }; $s | ||
| evalbot_r15025 | \"142242342" | ||
|
12:48
weinig|zZz is now known as weinig
|
|||
| pasteling | "fglock" at 201.35.169.13 pasted "a possibly saner implementation of BEGIN blocks run-time side-effects" (29 lines, 442B) at sial.org/pbot/22254 | 12:51 | |
| fglock | luqui: please see sial.org/pbot/22254 | 12:52 | |
| it would be nice to use this, because it has no impact on performance | 12:53 | ||
|
12:57
luqui joined
|
|||
| fglock | luqui: hi :) | 12:57 | |
| luqui | hello fglock | 12:58 | |
|
12:59
kanru joined
13:01
lumi joined
|
|||
| fglock | luqui: I found that I can use closures to init lexicals at any pad level - see sial.org/pbot/22254 | 13:03 | |
| it's much cleaner | |||
|
13:04
Limbic_Region joined
|
|||
| luqui | hmm, I wonder why we didn't see that before... | 13:06 | |
| fglock | it comes from the background refactoring process in the brain - it's a low priority process | 13:13 | |
|
13:17
sunnavy joined
13:22
elmex joined
|
|||
| svnbot6 | r15026 | fglock++ | kp6 - added a note on pad accessors | 13:22 | |
|
13:51
dduncan left
13:53
gnuvince joined
14:04
vel joined
14:18
[particle] joined
14:25
Steve_p joined
14:29
Alias__ joined
14:36
finchely left
14:45
vel joined
14:51
kanru joined,
weinig is now known as weinig|bbl
14:55
iblechbot joined
14:59
Odin- joined
15:03
ruoso joined
15:08
xpika left
15:21
hexmode joined
15:27
fglock joined
15:37
bonesss joined
|
|||
| [particle] | how big (kb, #files) is the pugs test suite? | 15:41 | |
| don't have svk, so it's hard for me to measure | |||
| allbery_b | 20.5k, 2138 files in my pugs/t | 15:43 | |
| that's not excluding .svn though, whoops | |||
| [particle] | is that an svn working copy? | ||
| allbery_b | 759 files | 15:44 | |
| yes | |||
| [particle] | thanks | 15:59 | |
| gaal | actually it's more like 1.7MB :) | 16:00 | |
| allbery_b | hm right, du defaults to 512-blocks on here and I didn't exclude the svn foo etc. | ||
| [particle] | gaal: where are BEGIN/END blocks stored in pugs ast? | ||
| allbery_b | and probably did other things wrong | ||
| [particle] | 627 files? | ||
| gaal | [particle]: begin is folded in, and leaves no trace in the ast | 16:01 | |
| END gets pushed to a @*END magical | |||
| [particle] | same for check/init? | ||
| gaal | hm i think so let me look | 16:02 | |
| yes indeed. see vcode2checkBlock etc. in Pugs.Parser cicca ln. 1091 | 16:03 | ||
| *circa | |||
| [particle] | kthanks | ||
| gaal | sure | ||
| [particle] | we'll soon have that functionality in past | ||
| gaal | yay | 16:04 | |
| <3 "we will .. in past" | |||
| fglock | is p6 supposed to support this: my @a[10] = 20; | 16:06 | |
| gaal | sure | ||
|
16:06
thepler joined
|
|||
| gaal | oh, with a my... not sure :) but i think so. :-) | 16:06 | |
| fglock | lexiacally 'shadow' a data structure's element | 16:07 | |
| lexically | |||
| [particle] | gaal: so, the result of begin is converted to ast and injected? | 16:08 | |
| nothingmuch | does lexical scoping even make sense here? | 16:09 | |
| i mean, pads are shadowed lexically because they are an opaque data structure | |||
| gaal | the result of a begin is a value. it might have had other enviromental side effects, but basically yes, it's folded to a context and injected to the compunit's ast | ||
| nothingmuch | it has no addressible origin | ||
| fglock | ?eval my $s; my @a=1..5; { my @a[2]=42; $s= ~@a; }; $s | ||
| evalbot_r15026 | \" 42" | ||
| gaal | srry bbiab.. | ||
|
16:10
tewk joined
|
|||
| svnbot6 | r15027 | andara++ | [runpugs] | 16:10 | |
| r15027 | andara++ | -release of what was the 'devel' version, v0.3.0 | |||
| r15027 | andara++ | -window/tab close now terminates session. Thanks diakopter. | |||
| r15027 | andara++ | -for those who didn't use the devel version: it's much faster now | |||
| fglock | I need to modify an array element lexically | 16:15 | |
| that's for implementing things like: my multi infix:<+> {...} | 16:17 | ||
| lexical modifications to the global grammar | |||
| hmm - it could be local'ized instead, by resetting to the old value on LEAVE | 16:18 | ||
| svnbot6 | r15028 | seano++ | Another "99 problem", perl5-style. | ||
|
16:19
GabrielVieira joined
|
|||
| fglock | GabrielVieira: ola | 16:19 | |
| GabrielVieira | fglock flavio my master! :) | 16:20 | |
| fglock | heh | ||
| kolibrie | fglock: but that is 'temp' - I don't know how 'my' should work in your example, or if it is even legal, because the array was already 'my'-ed | 16:29 | |
| fglock | hmm - @P6::Grammar::infix{'+'} needs to dispatch from the caller's pad POV | ||
| TimToady | I think it probably parses (my @a)[2] | 16:30 | |
| and that hides the outer @a | 16:31 | ||
| fglock | yes | ||
| I'm now trying to find out how 'my multi infix:<+> is parsed ... {...}' interacts with '@P6::Grammar::infix{'+'}' | 16:32 | ||
| TimToady | fglock: yes, you have to keep track of the grammar the user thinks they're using. | ||
| fglock | is it a kind of shadow over the global value | 16:33 | |
| TimToady | the macro part shadows, but has the same effect of dispatching to a normal multi | 16:34 | |
| and a normal "my multi" just hides that "long name" | |||
|
16:35
mbradley joined
|
|||
| TimToady | in other words, my multi infix:<+> doesn't have to do anything to the infix table if it's already there. | 16:35 | |
| fglock | got it | 16:36 | |
| TimToady | the infix table just turns $a + $b into infix:<+>($a,$b) and then normal multi takes over | ||
| fglock | and the parser executes in the current block's compile-time context | ||
| TimToady | so don't need to temporize table for that. | ||
| as we used to say with P5, a local at compile time is a my at run time | 16:37 | ||
| or something like that | |||
| if you do add a new infix, then you have to compile-time temporize something | 16:38 | ||
| whether it's the whole infix table, or a shadow mask... | |||
| or, I suppose, if you change the associativity or precedence of + | 16:39 | ||
| course, it does hurt anything except performance to temporize unnecessarily. | 16:40 | ||
| (in theory) | |||
| s/does/doesn't/ | 16:41 | ||
|
16:41
buetow joined
|
|||
| TimToady | obviously I need my coffee... | 16:41 | |
| fglock | thanks - I got the idea | 16:42 | |
|
16:46
ashleyb joined
16:49
nipra joined
|
|||
| GabrielVieira | fglock pvt? | 16:52 | |
|
16:56
GabrielVieira2 joined
16:59
buetow joined
17:00
Lunchy joined
17:18
andara left,
maquis joined
17:21
fglock joined
17:28
fglock joined
17:37
seano joined
17:56
GabrielVieira joined
18:01
justatheory joined
|
|||
| fglock | p6hack + $work is a bit confusing :) | 18:02 | |
|
18:12
diotalevi joined
|
|||
| TimToady | yes, especially if $work->perl5() | 18:15 | |
| wolverian | I considered trying to use perl6 for my data structures course project, but perhaps haskell is more realistic at this point | 18:16 | |
| (fortunately the graders don't really care that much about the language, so I don't have to use java) | |||
|
18:18
weinig joined
|
|||
| fglock | actually, right now, work = drawing comics for our web page :) | 18:18 | |
| luqui | wolverian, haskell might throw them for a thunk | 18:22 | |
| data structures in haskell are a little... different :-) | |||
| wolverian | true enough. :) | 18:23 | |
| luqui | \f -> f 1 2 -- oh yeah, that's just the tuple (1,2) | 18:25 | |
| fglock | I've been switching between p6/p5 too often lately - it's no longer a problem | 18:26 | |
|
18:27
seano joined
|
|||
| TimToady | that's the problem with Haskell--you have to say "oh yeah" on just about every line... | 18:33 | |
| every function is a brain pretzel | 18:34 | ||
| luqui | eh, no, just the fun ones | ||
| allbery_b is gradually getting past that point | |||
| masak | will computers be doing programming in the future, I wonder | 18:35 | |
| luqui | a lot of, say, pugs is pretty everyday code, once you grok the (many) haskell idioms | ||
| masak, either no, or they are already | |||
| allbery_b | masak: they've been predicting that since the 50s or earlier :) | ||
| luqui | (define your terms!) | ||
| masak | luqui: I don't mean metaprogramming, or other such things | 18:36 | |
| TimToady | computers are doing most of the programming these day; problem is you have to specify the problem for them in a higher level language | ||
| masak | I mean the whole thing, from innovation via design to implementation | ||
|
18:36
jabbot joined
|
|||
| masak | TimToady: I don't mean compilation either | 18:36 | |
| (seems I'm mostly defining what I _don't_ mean :) | |||
| TimToady | my point is that "innovation" is open-ended | 18:37 | |
| luqui | innovation is the hard one | ||
| masak | TimToady: point taken | ||
| TimToady | once computers can do part of it, the def changes | ||
| luqui | perhaps someday programming will be something like what automated proof checkers are... | ||
| er, proof generator | |||
| s | |||
| you can tell the computer "prove this" | |||
| and it will crank and crank (for many many hours for even the simplest things :-) | |||
| and then say "here you go" | |||
| but a computer has no idea what is interesting to prove | 18:38 | ||
| masak | I think a computer doing large parts of a human's programming project would pass my definition | ||
| TimToady | trouble is, for lots of useful problems you need a computer the size of the universe. | ||
| luqui | masak, then I think yes | ||
| masak | ok, next question: will they have coding standards? will they care? | ||
| will the standards be anything like human standards? | |||
| will different computers prefer different languages? the same languages as humans? | 18:39 | ||
| TimToady | my son Aron is currently off at a conference where they're trying to figure out if the universe has coding standards. :) | ||
| masak | probably in 50 years these questions will seem as naive as a person from the year 1900 asking questions about today's programming languages :) | ||
| TimToady | well, if we're lucky bitrot will have expunged these irc logs by then... | 18:40 | |
| masak | TimToady: the biological part of the universe certainly doesn't, so far as we know anyway | ||
| luqui | to be sure :-) | ||
| (to the "in 50 years" comment) | |||
| TimToady | well, but nothing is better at innovation than biological systems | 18:41 | |
| luqui | touche | ||
| TimToady | see H5N1 | ||
| wolverian | it's so very slow though :) | ||
| TimToady | we sincerely hope H5N1 is slow | 18:42 | |
| wolverian | I meant biological systems in general, as compared to silicon. | ||
| (okay, I've read too much egan.) | |||
| TimToady | it's the price of cheating | ||
| luqui | hey, a few billion years is no time to wait when comparing how long it takes to break a 4096 bit rsa key | 18:43 | |
|
18:43
cdfh_ joined
|
|||
| TimToady | the fastest way for biology to deal with that is to invent a species that can deal with it. | 18:44 | |
| luqui | I wonder if nature could innovate a way to do that faster than brute force could.. | ||
| TimToady | unfortunately nature likes to observe its own qubits | 18:45 | |
| but nature has provably produced a species that would like to avoid watching 4096 qubits for "long enough" | 18:46 | ||
| luqui | provably? which one? | ||
| oh | |||
| duh | |||
| luqui feels smrt | |||
| allbery_b | heh | 18:47 | |
| TimToady | the sme species tht would like to mke computers smrter thn themselves. | ||
| Gothmog_ | luqui: It would take long to brake with the current knowledge, but it's not even proven that prime factoring is NP-hard, let alone the P/NP problem. | 18:48 | |
| luqui | details, details | ||
| Gothmog_ | Just wanted to quibble a bit. ,-) | 18:49 | |
|
19:00
ozo_ joined
19:03
elmex joined
|
|||
| fglock | just checking - when I say 'my multi infix:<+> {..}' is it 'OUTER' to the parser? | 19:14 | |
| awwaiid | isn't factoring np-complete? | ||
| awwaiid reads wikipedia to find out that it isn't | 19:15 | ||
|
19:17
GabrielVieira2 joined
|
|||
| wolverian | awwaiid, it is believed to be in NP but not NP-complete | 19:18 | |
| masak | I kinda imagine that computers would have the same reasons for wanting to program in HLLs as we humans do | ||
| awwaiid | lazy bastards | ||
| masak | :) | ||
| I mean, it hides complexity for us, it should for them too, right? | |||
| awwaiid | yes... but what is our motivation for hiding complexity if it isn't limited ability to hold it all in our minds at once... I imagine a super-brain (smart enough to hold the entire compiler in their mind instantly) would find actually _using_ a compile pointless. | 19:20 | |
| we have a mind-body problem, they will have a mind-othersoftware problem | |||
| [particle] | i don't find calculators useless | 19:21 | |
| masak | awwaiid: they would also have limited ability to hold it all in their minds at once... the limits might be farther away, but they'd be there | 19:22 | |
| TimToady | fglock: I don't know what you mean by "OUTER". are you asking what the global ramifications of "my multi" are? | ||
|
19:22
diakopter joined
|
|||
| awwaiid | masak: good point | 19:23 | |
| wolverian | just build more computronium. | ||
|
19:23
mbradley joined
|
|||
| wolverian | I wish humans ran on extensible hardware. | 19:24 | |
| masak | wolverian: they do | ||
| my glasses are an extension to my eyes | |||
| wolverian | I meant human minds. | ||
| but, point. :) | |||
| masak | well, my mind uses my eyes as hardware... | 19:25 | |
| wolverian | right. | ||
| fglock | TimToady: I mean, the parser sees the lexical declaration | ||
| wolverian | it's like buying a new webcam versus buying a better CPU | ||
| TimToady | leaving aside the infixness, any "my multi" is used only within dispatches originating from that lexical scope. | 19:26 | |
| the scope of the infix "macro" is the same. | |||
| masak | wolverian: what is like buying a new webcam versus buying a better CPU? | 19:27 | |
| [particle] | hrmm, will @?BEGIN, @?END be available? | 19:28 | |
| wolverian | masak, getting glasses versus mind-augmentation. | ||
| TimToady | when you're building the candidate list for a particular multi dispatch, it goes outward in the scopes and finds any candidates whose long name is not hidden by an inner scope | ||
| fglock | I think what I mean is, the whole grammar is inside the scope | ||
| TimToady | finally it adds in all the global multies | ||
| wolverian | (the latter is what I meant with "extensible hardware") | ||
| TimToady | logically, yes | ||
| wolverian | although I wonder what psychedelics are analogous to. | ||
| TimToady | reverts to previous grammar at } | ||
| fglock | rather than being a simple external module | ||
| masak | wolverian: ah. ... yes. | 19:29 | |
| TimToady | yes, you generally have to construct an anonymous grammar | ||
| and that anon grammar may well be based on the OUTER:: anonymous grammar | |||
| the current grammar is also passed to eval, i think. | |||
| but not to require | 19:30 | ||
| so in the case of eval you need to remember the current grammar in $?GRAMMAR till run time | |||
| that anonymous grammar is where you probably want to store the modified infix etc. tables | 19:31 | ||
| fglock | ok! | ||
| TimToady | rather than just temporizing, or in addition to temporizing | ||
| masak | wolverian: I don't think psychedelics necessarily have an equivalent in the computer world, though that's quite a bland answer, admittedly. the thing that psychedelics disturb (something along the lines of "a consistent conscious experience") doesn't have an analogue in the software world. | 19:32 | |
| TimToady | basically a GC problem; if anything refers to $?GRAMMAR you keep it around. | ||
| wolverian | masak, right. yet, anyway. :) | ||
| TimToady | multithreading seems to be related. :) | 19:33 | |
| if this conversation is any clue | |||
| masak | TimToady: :) | 19:35 | |
| allbery_b | <mike> I conjecture it is similar to a slight overvoltage </mike> | ||
| TimToady | more like changing the damping characteristics of back-and-forth interactions, I suspect | 19:37 | |
| maybe when computers can have epileptic fits, they can go psychedelic | |||
| anyway, moving from hard locking to STM may get us closer | 19:38 | ||
| next is PTM, psychedelic transcendental memory | 19:39 | ||
| masak | *lol* | ||
| masak would like to see an SPJ paper on that | |||
| probably, there will never really be a stage where we'd say "well, now it seems that computers really program themselves" | 19:41 | ||
| either it'll never happen or it already happened, depending on one's definitions | |||
| fglock | is a BEGIN block compiled, and then executed - or is it compiled/executed a statement at a time | 19:42 | |
| masak | but what we'll probably see increasingly is computers hooking up to each other and telling each other what to to, in increasingly complex and seemingly aware ways | 19:43 | |
| PerlJam | fglock: what an odd question. | ||
| masak | fglock: is the difference noticeable in any way? do you have a code example? | ||
| PerlJam | fglock: I've always thought it the former. I guess thinking about the other is what strikes me as odd. | 19:44 | |
| fglock | PerlJam: I'm just checking - because I'm working on it right now... | ||
| TimToady | BEGIN just compiles like a normal closure, but executes after final } | 19:45 | |
| fglock | it can have a BEGIN inside it, right? | ||
| [particle] | executes as soon as possible | ||
| TimToady | yes | 19:46 | |
| but you don't need statement granulatity on you compiler pipeline | |||
| masak | what about a BEGIN with an END in it? | ||
| TimToady | closure granularity is good enough | ||
| fglock | ok | 19:47 | |
| TimToady | the END doesn't care | ||
| still executes when the run-time is exiting | |||
| masak | ah | ||
| reasonable | |||
| TimToady | all END/CHECK/INIT do are push a closure on a queue | ||
| or whatever correct English for that is... | 19:48 | ||
| well, push or unshift, depending on the order used for that kind of block... | 19:49 | ||
| gaal | "append"? | ||
| TimToady | either that or the caller runs in the other order. | ||
| gaal | or even "put" | ||
| TimToady | pend this to that list | 19:50 | |
| gaal | app-END{} | ||
|
19:50
justatheory joined
|
|||
| TimToady | perhaps just push everything and let the caller decide pop vs shift. | 19:50 | |
| then the list always reflects lexical order, for which there is something to be said. | 19:51 | ||
| especially if people add new blocks with weird execution orders, like dependencies that have to be calculated at run time. | 19:54 | ||
| fglock | TimToady: thanks for the explanations | 19:56 | |
| home & | |||
|
19:57
GabrielVieira2 is now known as GabrielVieira
20:02
azazello joined
|
|||
| svnbot6 | r15029 | fglock++ | kp6 - updated spec; added some experiments with begin-blocks | 20:11 | |
| masak | fglock++ # moving stuff forward | 20:15 | |
|
20:39
davidm123 joined,
davidm123 left
20:56
Aankhen`` joined
21:05
jferrero joined
21:08
bernhard joined
21:14
mdiep_ joined
21:48
diotalevi left
22:03
Limbic_Region joined
22:36
GabrielVieira2 joined
22:53
polettix joined
23:14
bonesss joined
23:18
diakopter left
23:21
hexmode joined
23:26
justatheory_ joined
23:34
mako132_ joined
23:51
xpika joined
|
|||