|
Parrot 3.1.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: ? Set by moderator on 20 February 2011. |
|||
| Tene | dukeleto: if you turn on "stacking", or whichever is "smoke every commit", when you finally push to smoke-me/foo, it will go back and smoke every commit on the branch, including the old busted commits. | 00:00 | |
| dukeleto | Tene: yes, i just realized that. | 00:01 | |
|
00:01
wknight-phone left
|
|||
| dukeleto | Tene: i guess, for now, we can leave stacking off | 00:01 | |
| Tene: but if we want it, we can get it. If we do, all branches in smoke-me/* will have all commits tested | 00:02 | ||
| Tene: as well as master | |||
| Tene: jitterbug is pretty flexible, and anything it can't do, I can add to it | |||
| Tene: i am just trying to find a nice workflow that give parrot devs feedback when stuff breaks | 00:03 | ||
| Tene: via email | |||
| Tene | dukeleto: We have a pretty strong tradition of breaking things in branches; I think it makes a lot of sense to leave stacking off. | ||
| dukeleto | Tene: sounds good to me. | ||
| Tene: if I add the ability to stack specific branches to Jitterbug, then we could make it only stack master | 00:04 | ||
| cotto_work | +1 to not complaining too much about broken branches. | ||
| Tene | dukeleto: if it stacks master, when you finally merge your branch in, it will go back and smoke all of the broken commits at the start of the branch | ||
| no? | 00:05 | ||
| dukeleto | Tene: touche. no stacking it is. | ||
| wfm, less code to write | 00:06 | ||
|
00:06
donaldh left
|
|||
| Tene | dukeleto: I could imagine an argument for running a limited subset of tests on every commit, but the argument I'm imagining isn't very persuasive. :) | 00:07 | |
| dukeleto | Tene: my favorite kind of argument to ignore ;) | 00:08 | |
|
00:16
kid51 joined
|
|||
| cotto | ~~ | 00:42 | |
| kid51 | ~~ | 00:46 | |
|
00:48
kid51 is now known as kid51_at_dinner
00:57
dolmen left
|
|||
| dalek | rrot: 69fcf0a | mikehh++ | tools/dev/ncidef2pir.pl: fix perlcritic failure - String delimiter used with "split" |
01:18 | |
|
01:39
dmalcolm left
|
|||
| mikehh | still getting server problems trying to upload to smolder - HTTP CODE: 500 (Internal Server Error) | 01:43 | |
| kid51_at_dinner | mikehh: I was getting that about 24 hours ago. Then it appeared to have cleared up. Started bug ticket with OSL, no response yet. | 01:44 | |
|
01:44
kid51_at_dinner is now known as kid51
01:45
cotto_work left
01:47
cotto_work joined
01:49
rblackwe joined,
rblackwe_ left
|
|||
| dalek | rrot: 2e24c69 | mikehh++ | docs/index/tools.json: change tools/dev/ncidef2pasm to ncidef2pir |
01:50 | |
| mikehh | kid51: I have been getting it since about 8 or so hours ago, tried about 5 uploads | 01:52 | |
| they have all failed | 01:53 | ||
| dalek | rrot: 3da9455 | bacek++ | t/pmc/hash.t: Add test for VTABLE_hashvalue. |
02:09 | |
| mikehh must get sleeeepp | 02:11 | ||
| cotto | mikehh, 'night | 02:13 | |
| much better than going to schlep | 02:14 | ||
|
02:16
bluescreen left
02:23
bubaflub joined
|
|||
| dalek | rrot/jkeenan/tt1159_distcheck: a488957 | jkeenan++ | / (2 files): First draft of 'make distcheck'. |
03:27 | |
| rrot/jkeenan/tt1159_distcheck: 6a054a6 | jkeenan++ | config/gen/makefiles/root.in: First draft of 'make distcheck': template. |
|||
| rrot/jkeenan/tt1159_distcheck: 2c5bd53 | jkeenan++ | / (2 files): Implement 'make distcheck' target via new program 'tools/release/distcheck.pl'. |
|||
|
03:28
preflex left
|
|||
| kid51 | Who is the March 15 release manager? Which file lists that? | 03:33 | |
| dalek | rrot: 21ec453 | petdance++ | compilers/opsc/src/Ops/Trans/C.pm: remove unnecessary interp argument from store_op() and calls |
03:35 | |
| kid51 | seen petdance? | 03:37 | |
| aloha | petdance was last seen in #perl6 87 days 23 hours ago joining the channel. | ||
| bacek_at_work | seen andy | ||
| aloha | andy was last seen in #parrot 6 hours 6 mins ago saying "Tease.". | ||
| bacek_at_work | kid51, ^^ | ||
| kid51 | A man of multiple identities! | ||
|
03:49
bubaflub left
|
|||
| cotto | aloha, release manager guide? | 03:49 | |
| aloha | cotto: I give up. | ||
|
03:51
kid51 left
03:52
JimmyZ joined,
preflex joined
04:25
akashmanohar joined
|
|||
| akashmanohar | Hi all. | 04:26 | |
| Can anyone point me to docs on writing extensions/libraries to parrot using PIR or the Parrot C API? | |||
| JimmyZ | Hello akashmanohar, what do you want to write? | 04:30 | |
| akashmanohar | JimmyZ: I'm looking at writing a memcached lib for the parrotvm. but i want to start off with small stuff first like a lib that says hello world | 04:34 | |
| JimmyZ | akashmanohar: I think you want docs.parrot.org/parrot/latest/html/...l.pod.html ? | 04:36 | |
| akashmanohar | JimmyZ: thanks! | 04:37 | |
| JimmyZ: I just came to my senses. Writing extensions in C would have to take care of plat dependent stuff. Does that doc apply to PIR-based extensions too? | 04:38 | ||
| JimmyZ | akashmanohar: yes | 04:39 | |
|
04:40
eternaleye left
|
|||
| JimmyZ | akashmanohar: you dont' need parrot C api unless you want to embed parrot to other apps or improve parrot itself. | 04:42 | |
| akashmanohar | JimmyZ: okay. i'm confused. What I want to do it write a memcached lib for parrotvm that languages running on parrot can use. | 04:43 | |
|
04:44
mtk left
|
|||
| akashmanohar | JimmyZ: the last chat I had here, I was advised to skip C and look at writing extensions using PIR (sorry, i just remembered that). And aren't there any articles/docs on this? | 04:44 | |
| apologies if I asked too many questions. I'm just beginning to understand how to write libraries for parrot. | 04:45 | ||
| JimmyZ | akashmanohar: there are some libs in parrot, see github.com/parrot/parrot/tree/mast...ot/library | 04:46 | |
|
04:47
eternaleye joined
|
|||
| JimmyZ | akashmanohar: questions are welcome :) | 04:47 | |
| akashmanohar | JimmyZ: thank you! a lot of libs there. I found this small one for Math random here github.com/parrot/parrot/blob/mast...h/Rand.pir sounds like a good start | 04:50 | |
| JimmyZ | akashmanohar: you are welcome, hehe | ||
|
04:51
mtk joined
|
|||
| dalek | rrot: 197839d | util++ | src/oo.c: Fix Coverity defect #500: PW.PARAMETER_HIDDEN in oo.c |
04:59 | |
| rrot: 3aef68e | util++ | compilers/imcc/optimizer.c: Fix Coverity defect #476: PW.PARAMETER_HIDDEN in optimizer.c |
05:01 | ||
| cotto | Util++ | 05:09 | |
| thanks for knocking some of those out | |||
| bacek_at_work | Util, ping | 05:11 | |
| Util, unping. I replied to your mail. | 05:14 | ||
| Util | cotto: Glad to help. 5 down, 898 to go :) | 05:16 | |
| Although I am hopeful that bacek++ "Rebootstrap ops" commit will resolve 570 UNUSED_VALUE defects from core_ops.c | |||
| cotto | heh | ||
| Util | bacek_at_work: Thanks for your prompt attention. Shall I commit? | 05:17 | |
|
05:24
akashmanohar left
|
|||
| dalek | rrot: da90aa3 | util++ | src/gc/gc_gms.c: Move parenthesis in POBJ2GEN for clarity and correctness. |
05:25 | |
| bacek_at_work | Util, go for it | 05:38 | |
| Util, yes, "Rebootstrap ops" should resolve unused variables :) | |||
| dalek | rrot: 9236c91 | util++ | src/gc/gc_gms.c: Remove unneeded parameter. Also fixes Coverity defect #1297: PW.PARAMETER_HIDDEN in gc_gms.c |
05:56 | |
| Util | $clock == Midnight; sleep & | 06:02 | |
|
06:14
rurban_ joined
06:17
rurban left,
rurban_ is now known as rurban
|
|||
| cotto | dukeleto, ping | 06:30 | |
| dukeleto | cotto: pong | 07:01 | |
|
07:01
theory left
|
|||
| cotto | dukeleto, have you given any thought to what atoms would be necessary to enable dlfunc et al to be used by M0 code? | 07:05 | |
|
07:07
fperrad joined
07:24
ShaneC left
|
|||
| NotFound | cotto: Shouldn't that be several levels up to M0? | 07:29 | |
| cotto | NotFound, there needs to be some way to generate M0 code that allows a shared library to be loaded and used. | 07:32 | |
| We won't get far interacting with the C parts of Parrot and external libraries like icu otherwise. | 07:33 | ||
| NotFound | cotto: if M0 can call C functions, you just need to call the system functions that do that. | 07:34 | |
| cotto | NotFound, sure. An important question is how it'll do that. | 07:35 | |
| NotFound | Oh | ||
| So the questio is how to call C? | 07:36 | ||
| cotto | that and how to dtrt when dealing with shared libraries. But the C question is more important atm. | ||
| er, how to make it possible to dtrt. M0 shouldn't have enough smarts to dtrt on its own. | 07:37 | ||
| NotFound | I think that way may lead to integrating almost all NCI in M0, wich may lead to add another level below M0 %-) | 07:39 | |
| cotto | M4294967295 | 07:41 | |
|
07:41
cosimo left
|
|||
| dukeleto | cotto: good question | 07:41 | |
| NotFound: dlfunc will be at a level above M0, but the atoms to build dlfunc need to exist in M0 | |||
| cotto | We can use the current NCI system as a starting point. | 07:42 | |
| dukeleto | cotto: how much NCI is needed at M0 seems to be the question | 07:43 | |
| dalek | rrot: ff9918a | (Gerd Pokorra)++ | lib/Parrot/Docs/Section/Tools.pm: change to renamed file to fix "make html" |
||
| cotto | dukeleto, yup | ||
| If M0 can access arbitrary regions of memory, we're partly there. | 07:45 | ||
|
07:47
ShaneC joined
|
|||
| dukeleto | cotto: yes. dlfunc mostly boils down to looking up function signatures and fiddling with memory | 07:48 | |
| cotto: as far as I can tell | |||
| NotFound | If you want to be able to call any C function, I'd call that full NCI. | ||
| cotto | dukeleto, sure. We can treat it as a black box, | ||
| ShaneC | how would i go about doing what configure.pl does, but specifying values instead of letting it pull them from perl | ||
| im on windows, and i don't want it to pull info from activeperl | |||
| cotto | NotFound, just the most useful ones for now. We won't be doing opengl with M0 for a while. | ||
| ShaneC, trac.parrot.org/parrot/wiki/Platforms/Windows | 07:49 | ||
| ShaneC | cotto: thanks, i'll give that a try | ||
| cotto | if that doesn't help, let us know | ||
| ShaneC | still getting: compilation failed with 'cl' | 07:50 | |
| i'm in the proper command prompt that has all of the vs env vars set up properly | 07:51 | ||
| i can run cl | |||
| cotto | ShaneC, can you nopaste what's going on? I likely need to let myself fall asleep soon, but someone else may be able to help you. | 07:52 | |
| aloha, nopaste? | 07:53 | ||
| aloha | cotto: nopaste is is nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl) | ||
| ShaneC | nopaste.snit.ch/33885 | ||
|
07:54
NotFound is now known as Themeruta
|
|||
| dukeleto | ShaneC: try perl Configure.pl --help | 07:54 | |
| Themeruta | Parrot Version 2.9.1? | 07:55 | |
| dukeleto | ShaneC: there is a --file option or something like that, to specify a file which sets the config variables | ||
| ShaneC: also, welcome! | |||
| ShaneC | thanks ;-) | ||
| basically i dont want it pulling anything from my activeperl | |||
| cotto | My work machine does fine with Strawberry Perl for both the msvc and mingw toolchains. | 07:56 | |
|
07:56
Themeruta is now known as NotFound
|
|||
| ShaneC | id prefer not using mingw or cygwin | 07:56 | |
| i work on video games and those often conflict with sony/nintendo's stuff | 07:57 | ||
| cotto | your call | ||
| dukeleto | ShaneC: i am trying to find the option to Configure.pl | ||
| NotFound | ShaneC: execute this: cl /? | 07:58 | |
| ShaneC | C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC>cl /? | ||
| Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 | |||
| or do you need all of the arguments? | |||
| NotFound | I'm just trying to figure why $msvcversion gets unitialized. | 07:59 | |
| dukeleto | ShaneC: perl Configure.pl --file=foo.txt | 08:00 | |
| ShaneC: perldoc Configure.pl to read about how to use --file | |||
| ShaneC | will do | 08:01 | |
| got a link to that doc by chance? | 08:02 | ||
| my perldoc is not cooperating | |||
| NotFound | $cc /? 2>&1 --> 2>&1 works in cmd.exe ? | 08:04 | |
| ShaneC | 2>&1 was unexpected at this time. | 08:05 | |
| NotFound | Someone with msvc should review and fix config/init/hints/mswin32.pm | 08:07 | |
| dukeleto | ShaneC: i don't think we have the perldoc output of Configure.pl anywhere public, sadly | 08:09 | |
|
08:10
mikehh left
|
|||
| ShaneC | alright, thanks for the help -- maybe i'll just lose activeperl and build my own p5 first | 08:10 | |
|
08:11
lucian joined
|
|||
| dukeleto | ShaneC: leto.net/tmp/Configure.pl.html | 08:11 | |
| ShaneC | thanks | 08:12 | |
| dukeleto | ShaneC: good luck | ||
| NotFound | ShaneC: if the problem lies in Configure and cmd interaction, switching perl will not solve it. | ||
| ShaneC | if i use the file interface that skips probing my perl right? | ||
| dalek | rrot: 46200ef | dukeleto++ | api.yaml: The hashvalue vtable will not be deprecated |
08:13 | |
| cotto | dukeleto, I'm glad that vtable function got some attention. Now we know what it's for and it's better-tested. | 08:14 | |
| cotto sleeps | |||
| NotFound | Well, maybe if it gets the value from perl config that branch of the prove doesn't get executed. | ||
| dukeleto | cotto: yep. all good vibes from just sitting down and writing tests and trying to figure out how our vtables work | ||
| ShaneC: i think you would have to override everything that perl gets asked, but i am not sure | |||
| NotFound | The conflicting point seems to be C optimize flags. | 08:15 | |
| Looks like the hints file does a check to avoid using unsupported optimizations when using the free versionof msvc. | 08:16 | ||
| ShaneC: you may try adding: --optimize=-O1 to Configure.pl options | 08:18 | ||
| ShaneC | thanks, afk for a bit, i'll read over and try some stuff when i get back | 08:19 | |
| NotFound | Or adding -O1 to --ccflags | ||
| dukeleto | cotto: re: trac.parrot.org/parrot/ticket/903 seems that about 40% or so of the vtables in extend_vtable.c are key-related | 08:21 | |
| cotto: removing keys will reduce the complexity of our vtable interface considerably | |||
| dalek | TT #2027 closed by dukeleto++: Deprecate hashvalue vtable | 08:25 | |
| TT #2027: trac.parrot.org/parrot/ticket/2027 | |||
| TT #2026 closed by dukeleto++: t/src/extend_vtable.t: Non-deterministic results | |||
| TT #2026: trac.parrot.org/parrot/ticket/2026 | |||
| NotFound | dukeleto: I don't thnk so. Most are pmc arguments that just happen to be keys most times. | 08:26 | |
| dukeleto | cotto: i stand corrected. It looks like 24% of the vtables in extend_vtable are key-related | 08:27 | |
| NotFound: still, we have a lot of vtables because of keys | 08:28 | ||
|
08:29
lucian left
|
|||
| dukeleto | NotFound: if we could use pmc vtables instead of having special key vtables, that reduces the number of vtable functions considerably, no? | 08:29 | |
| NotFound | dukeleto: because of keyed access, not because of the Key pmc. | ||
| dukeleto: we do have pmc vtables, and in most PMC they aren't limited to Key arguments. | 08:30 | ||
| Must go, SYL. | 08:36 | ||
| ShaneC | ideally i'd like to create a parrot vcproj/sln | 08:37 | |
| can someone show me what their config.h looks like? | 09:17 | ||
| almost have the vs build working | 09:30 | ||
| i'd love to keep that maintained too, a lot of windows devs would probably appreciate that | |||
|
09:47
benabik joined
10:39
particle left
10:41
particle joined
10:43
AzureStone left
10:46
AzureStone joined
10:52
AzureStone left
10:53
AzureStone joined
11:07
lucian joined
|
|||
| dalek | rrot/opsc_full_parse: 94d9041 | bacek++ | / (2 files): More tweaks of Grammar |
11:15 | |
|
11:48
JimmyZ left
12:05
bluescreen joined
12:11
krunen joined
|
|||
| dalek | rrot/opsc_full_parse: c00dd2a | bacek++ | compilers/opsc/src/Ops/Compiler/ (2 files): Distinguish between pod ws and C ws. Handle C macros properly |
12:26 | |
|
12:31
mtk left
12:38
mtk joined
|
|||
| dalek | rrot/opsc_full_parse: 50df85d | bacek++ | compilers/opsc/src/Ops/Compiler/Grammar.pm: Remove misleading comment |
12:43 | |
|
12:45
mikehh joined
12:47
bluescreen left
12:55
lucian left
13:01
lucian joined
|
|||
| dalek | rrot/opsc_full_parse: 66a93ed | bacek++ | compilers/opsc/src/Ops/Compiler/Grammar.pm: Change <type_indetifier> to avoid false positives. |
13:11 | |
|
13:15
whiteknight joined
|
|||
| whiteknight | good morning, #parrot | 13:15 | |
| dalek | rrot: b8ee160 | (Gerd Pokorra)++ | config/gen/makefiles/root.in: add more dependencies for the EXTRANCITHUNKS_SO definition, this is a preparation for a JSON_nqp branch, but this should still can go to the master branch |
13:25 | |
|
13:27
lucian left
13:42
lucian joined
|
|||
| whiteknight | kid51: ping | 13:43 | |
| msg kid51: I'm getting a test failure in t/perl/Parrot_Test.t on the whiteknight/imcc_compreg_pmc branch. It's a test for pir_error_output_is, and I don't really understand why it's failing or how to fix it. Could you take a look at it, when you get a spare moment? Thanks | 13:47 | ||
| aloha | OK. I'll deliver the message. | ||
|
13:52
jsut_ joined
13:56
jsut left
13:59
lucian left
|
|||
| dalek | rrot/gerd/JSON_nqp: 3f7c693 | (Gerd Pokorra)++ | tools/dev/nci_thunk_gen.pir: add new JSON API to file "nci_thunk_gen.pir" |
13:59 | |
|
14:12
JimmyZ joined
14:14
rurban_ joined
14:17
rurban left,
rurban_ is now known as rurban
14:37
fperrad left
14:59
worr joined
15:34
Andy joined
|
|||
| dalek | rrot: b49a5cc | (Gerd Pokorra)++ | t/op/gc-non-recursive.t: in non-optimized builds this test will be disabled |
15:39 | |
|
15:45
plobsing joined
15:50
plobsing_ left
|
|||
| whiteknight | building the whiteknight/imcc_compiler_pmc branch with g++ is the failz | 15:58 | |
| on the bright side, the fixes help to futher insulate IMCC from libparrot | 16:05 | ||
|
16:05
kj joined
16:06
kj is now known as kjs
|
|||
| whiteknight | is there a way I can add stuff into a generated pmc .c file BEFORE the list of includes? | 16:12 | |
| blah | 16:13 | ||
| dalek | rrot/whiteknight/imcc_compreg_pmc: 9222efd | Whiteknight++ | / (13 files): Add a new imcc/embed.h include file. This is the file libparrot would use to call into IMCC. Nobody should be using compilers/imcc/imc.h directly anymore, outside IMCC itself. The build is now broken because of problems in IMCCompiler PMC, but the g++ build is in much better shape. |
16:15 | |
| whiteknight | if I can rearrange that the #includes in src/pmc/imccompiler.c, I think I can fix the build for gcc and g++ | 16:16 | |
|
16:18
Psyche^ joined,
Patterner left,
Psyche^ is now known as Patterner
|
|||
| kjs hopes that, some day, on a good day, PIRC will be able to replace IMCC | 16:18 | ||
| JimmyZ | somebody hopes pirate :) | 16:19 | |
| JimmyZ doesn't know which one is better. | 16:20 | ||
| tadzik | one was to use tree-optimizer | 16:21 | |
| Coke | msg dukeleto the current board should have admin rights on all the mailing lists. | 16:24 | |
| aloha | OK. I'll deliver the message. | ||
| Coke | kjs: pirc is pretty much dead at this point - no one was able to integrate it into the build. | 16:26 | |
| kjs | Yeah, I know. I did compile, but it's not feature-complete. | 16:27 | |
| whiteknight | on the bright side, the threshold for "integrate into the build" is going to become much lower | 16:28 | |
| I think we're about 2 months away from IMCC being an optional configure-time option | |||
| well, 2 months away if we keep up this pace. I suspect other high priority things will take over | 16:29 | ||
| one day, all you'll need to do is provide a libparrot-pirc binary, and load it in | 16:30 | ||
| tadzik | aloha: imcc? | 16:36 | |
| aloha | tadzik: imcc is just a prototype example | ||
| tadzik | mhm | ||
| whiteknight resists the urge to update the imcc entry and teach poor aloha any new curse words | 16:37 | ||
|
16:45
JimmyZ left
16:47
theory joined
|
|||
| cotto_work | ~~ | 17:39 | |
| whiteknight | cotto_work: good morning | ||
| cotto_work: I have a question you might be able to answer, if you have a spare moment | 17:40 | ||
| cotto_work | whiteknight: fire away | 17:41 | |
| whiteknight | cotto_work: I need to include a .h file in a .pmc *before* pmc2c adds in all the standard headers | ||
| is there such a way? | 17:42 | ||
| cotto_work | How do you feel about hacking pmc2c? | 17:43 | |
| whiteknight | ha | ||
| okay, thanks. that's the answer I was expecting | |||
| one more roadblock on the way towards IMCC freedom | 17:44 | ||
| cotto_work | I suppose it's better that you need it for an internal user. | 17:45 | |
| whiteknight | I'm going to try to find a workaround first, then hack pmc2c | 17:46 | |
| I know g++ hates void*, it's just a matter of finding out how much it hates | |||
|
17:49
ShaneC left
|
|||
| whiteknight | actually, nevermind. I need to hack pmc2c anyway. It's mangling the names of header includes. | 17:53 | |
| is there an NQP version of it, or is it just tools/build/pmc2c.pl? | 17:54 | ||
| Coke | isn't there a PREAMBLE marker? | ||
| cotto_work | whiteknight: there's an nqp wip, but it's not complete afaik. | ||
| dukeleto | ~~ | 17:55 | |
| cotto_work | morning, dukeleto | ||
| Coke thinks that might have been for ops. ah well. | |||
| plobsing | whiteknight: I have BEGIN_PMC_HEADER_PREAMBLE in ptrbuf branch | 17:59 | |
| which I will be merging in a day or two | 18:00 | ||
|
18:02
ShaneC joined
18:10
kjs left
18:15
Coke left
18:16
Coke joined
|
|||
| whiteknight | plobsing: Okay. That's a good start. I still need to fix a problem with a mangled include name | 18:20 | |
| in the PMC, I'm doing #include "imcc/embed.h", which is in include/imcc/embed.h. Pmc2c adds that to the makefile as "imcc/embed.h" instead of "include/imcc/embed.h". Make fails because that file doesn't exist | 18:21 | ||
| Actually, searching through this code, I'm not even certain that Pmc2c does that | |||
|
18:22
dmalcolm joined
|
|||
| Coke | when in doubt, refer to them via ../ because I think pmc2c will leave it alone then. | 18:28 | |
| (or at least manipulate it properly.) | |||
| whiteknight | the mangler in question in config/auto/pmc.pm | 18:31 | |
| and I'm fixing it to allow include/imcc/*.h handling transparently | |||
| cotto_work | #include_without_mangling | 18:37 | |
| plobsing | #include should include. #import or #munge could mangle. | 18:39 | |
| whiteknight | nothing's really getting mangled per se. It's just not being fully-qualified like other files are | 18:40 | |
| so, I added that | |||
|
18:53
lucian joined
18:56
lucian_ joined
18:59
benabik left,
benabik joined,
lucian left
|
|||
| cotto_work | seen chromatic | 19:01 | |
| aloha | chromatic was last seen in #parrot 13 days ago saying "All of the core tests did pass for me, FWIW.". | ||
|
19:18
lucian joined
19:20
lucian_ left
19:34
lucian_ joined
19:35
lucian__ joined,
lucian_ left
19:37
lucian left
19:44
lucian joined
19:47
lucian__ left
20:18
mtk left
|
|||
| whiteknight | do IMCC optimizations work? Do they ever get used or tested? | 20:21 | |
| I'm looking right now at the optimizations for converting recursive tailcalls into a loop, and it's....messy | 20:22 | ||
|
20:25
mtk joined
|
|||
| whiteknight | is github down? | 20:26 | |
| atrodo | seems up for me | 20:27 | |
| Least the website | 20:28 | ||
| plobsing | git fetch still works fine | 20:29 | |
| whiteknight | oh, it works now | 20:30 | |
| dalek | rrot/whiteknight/imcc_compreg_pmc: 0d03973 | Whiteknight++ | config/auto/pmc.pm: fix config/auto/pmc.pm to handle #includes of the form imcc/foo correctly |
||
| rrot/whiteknight/imcc_compreg_pmc: 4b4b869 | Whiteknight++ | / (5 files): several fixes for the c++ build. We still don't build with g++, and some of the weirder failures in IMCC are hard to fix |
|||
| cotto_work | whiteknight: they work at a basic level. Most are broken. | ||
| whiteknight | the recursive tailcall optimization has a pretty big base of code that is all...bad | 20:31 | |
| cotto_work | The only thing they do correctly is simple things like constant folding. | ||
| well, one of the only things | |||
| there might be a few others | |||
| whiteknight | I may want to rip a few of them out, eventually | 20:32 | |
| lower priority than ripping IMCC itself out | |||
| plobsing | the only reason IMCC does constant folding "correctly" is because it has to to properly generate PBC. add_i_ic_ic op is non-existant. | 20:34 | |
| cotto_work | plobsing: yes. That also means that PIRATE needs tree-optimization in order to be able to generate correct pbc. | 20:35 | |
| plobsing | btw, I disaggree with the particular def'n of "correct" used by IMCC constant folder. the way it handles folds that throw exceptions is... well... not good. | ||
| whiteknight | actually, the recursive tailcall optimization is causing a lot of heartache for the c++ build in my IMCC branch | ||
| which is the only reason I'm looking at the code now | 20:36 | ||
| NotFound | pir is a bizarre mix between a language and an assembler. On an assembler there will be a difference between the add opcode and the '+' in expressions. | ||
| plobsing | If we look at IMCC as an *assembler* there are a lot of things it shouldn't be doing. constant folding is one of them. TCO is another. let the HLL compilers worry about that. they are more likely to make better decisions because, in general, they have more information available. | 20:37 | |
| cotto_work | Those are among the many things that M0 won't do. | ||
| whiteknight | sometime, when you have some liquor in you, read through the source of src/utils.c:Parrot_util_register_move. | ||
| NotFound | plobsing: winxed does it | ||
| whiteknight | Then, when you're done reading it, realize that IMCC uses that function not to actually move registers, but to generate move instructions for them | ||
| plobsing | NotFound: yes. and it does it a damn sight better than IMCC. contextual information is deleted compiling down to PIR. | 20:38 | |
| whiteknight: if you'll like that, you might also like the basic-blocks optimizing code which we have to run because it expands out PCC-handling. | |||
| s/you'll/you/ | 20:39 | ||
| whiteknight | sometimes in my work, I find I really appreciate IMCC | ||
| othertimes, I get so disheartened by it | |||
| plobsing | also enjoy having to trapse through 3 different files to come to that realization | ||
| NotFound | The most importante features of an assembler are: generated correct code and get out of my way. | 20:40 | |
| whiteknight | there are some gems in here. But the cargo-culting, everything-for-everybody-but-not-really-anything-for-anybody mentality, the complete disregard for coding standards and best practices, the inability to separate out the working code from the half-working or only-half-implemented crap | ||
| it's all too much | |||
|
20:41
lucian_ joined
|
|||
| whiteknight | encapsulation is treated like a curseword in a foreign language | 20:41 | |
| sort of funny to say, when nobody is listening, but not used for anything | |||
| The real shame of it is that a "good", narrowly-focused IMCC would have made an excellent high-performance assembler for Parrot | 20:42 | ||
| NotFound | Is not that bad, actually. | ||
| whiteknight | but that potential is lost now, and we have a huge backwards-compatibility guarantee that prevents us from ever getting back to that point | ||
| plobsing | the problem was making it *the* interface to Parrot. after that, it died a death of a thousand cuts from people who didn't really care about IMCC but "just want to make this one thing work". Like me. Right now. ;) | 20:44 | |
|
20:44
lucian left
|
|||
| plobsing | I suspect the same will happen to anything we make *the* interface, unless we are particularily careful. | 20:44 | |
| whiteknight | plobsing: That's precisely why I am pushing to have *no* designated programming interface | 20:45 | |
| libparrot should take bytecode input only, and expose a limited embedding API only. | |||
| everything else should be handled externally | |||
| I'm purposefully ignoring extending | |||
| lucian_ | whiteknight: like any other scripting language implementation | 20:46 | |
|
20:46
lucian_ is now known as lucian
|
|||
| plobsing | whiteknight: the API is an interface. do not underestimate the power of "just one more thing". | 20:46 | |
| whiteknight | lucian: right. libparrot should be the runtime engine, not the assembler, the compiler, the frontend, or anything like that | ||
| plobsing: This is true, and I've done my damndest so far to prevent the embedding API from growing without bound | |||
| long term, it's a losing battle | 20:47 | ||
| lucian | a good example is python's, embedding has been neglected so much in favour of extending, that it's now inconvenient to embed | 20:48 | |
| well, a rather bad example in fact | |||
| but it still works, i've seen worse | |||
| plobsing | lucian: have you seen Perl 5's 'interface'? | 20:49 | |
| dukeleto has nightmares about it | |||
| lucian | plobsing: no, i've just heard stories | ||
| whiteknight | lucian: I thought python was embedded in everything | 20:51 | |
| hell, my toaster has a python interpreter for plugins | 20:52 | ||
| lucian | whiteknight: it is, it's still reasonable | ||
| it's just an example of something that could've been perfect, but isn't at all | |||
| although unlike lua, embedding is a significant minority | 20:53 | ||
| whiteknight | I look at python and it's everywhere. There is either a built-in python interpreter or a readily available python plugin for every program I use on a daily basis | ||
| my IRC client has a python plugin interface. my IM client. my text editor | |||
| cotto_work | gdb | ||
| whiteknight | The GIMP | ||
| dukeleto | GIMP and all my IRC clients have bindings to most dynamic languages, but I agree, python is more prevalent than others. | 20:54 | |
| whiteknight | I've programmed embedded devices in python | ||
| plobsing | whiteknight: that's not a strong argument. my irc client has a perl plugin. so does my text editor. hell my terminal is extensible with perl. | ||
| dukeleto | the first scripting language for GIMP was Perl, iirc, and irssi and weechat both support all major dynamic languages | ||
| whiteknight | plobsing: There are plenty of perl bindings out there too, but python is much more prevalent | ||
| lucian | whiteknight: think of it this way: there are tons more applications written in python that use C/C++ modules | ||
| whiteknight | lucian: right. I don't think I will ever write an XS module | 20:55 | |
| plobsing | I'm just saying prevalence or existance is by no means a measure of quality. | ||
| whiteknight | plobsing: I never said anything about quality, although quality can't hurt you | ||
| lucian | whiteknight: sure you will, cython is great | ||
| whiteknight | plobsing: What's most important is that the interpreter is *available*. | ||
| NotFound | I wrote a curses based text editor in C++ with perl embedded the past millenium and still use it today. | ||
| whiteknight | so long as the interpreter is available, people will use it to write plugins and mods for their favorite software | 20:57 | |
| and those same skills translate over to the next favorite piece of software | |||
| and here's the kicker: in theory, there's no benefit to having an embedded cython interpreter than having an embedded Parrot interpreter with the Pynie language pack | 20:58 | ||
| and if we can get to the point where we can say "replace your old collection of a dozen separate dynamic language interfaces with a single Parrot interface", we win | 20:59 | ||
| atrodo | whiteknight> I think that's the biggest win parrot could hope for | ||
| lucian | whiteknight: that'd take a lot of work, though | 21:01 | |
| whiteknight | and then when language designers see that Parrot is embedded in everything, and all you need to do to make your new language X work with your text editor and your IRC client, and your web browser, and whatever, is to write your compiler on Parrot that's a big draw for us | ||
| lucian | i'm specifically thinking of C extension modules for each of those languages | ||
| whiteknight | lucian: of course. it's not a snap of the fingers | ||
| lucian: obviously we don't maintain C-level compatibility with other interpreters or their modules | |||
| lucian | whiteknight: yeah, but most software depends on that | 21:02 | |
| whiteknight | but we do have the ability to reuse effort. You don't need an XS perl wrapper and a Python extension plugin for the same library | ||
| all you need is one NCI interface to that library for Parrot, and any language can use it | |||
| atrodo | But if people creating these things can spend X amount of time integrating parrot and get python/lua/etc or X*3 to integrate all three individually, I would expect them to choose parrot first | ||
| whiteknight | if your language can provide semantic wrappers and respect opaque pointers, you get a lot of stuff for free | 21:03 | |
| atrodo: right | |||
| our strength is numbers. Write once, run everywhere | |||
| NotFound | If we provide the means, writing replacements of current modules that keeps its interfaces shouldn't be too hard. | ||
| mj41 | hi. taptinder is back ... reposiotory loop was hanging since Tuesday | ||
| whiteknight | exactly | ||
| mj41++ | |||
| lucian | NotFound: in theory, yes. but look at CPython/PyPy | 21:04 | |
| and Jython and IronPython and so on | |||
| but specifically CPython vs PyPy is interesting because they overlap more | |||
| plobsing | in theory, simple XS should be trivially translatable to Parrot. in practice, almost no XS is that trivial. | ||
| whiteknight | we're never going to be the only game in town, because we're never going to be able to optimize any particular language as much as a dedicated interpreter/compiler could do | 21:05 | |
| theory eats XS, poops out Parrot | |||
| whiteknight | but we can benefit from being competitive and offering huge economies of scale | ||
| NotFound | plobsing: to be able to translate the code someone should be able to understand it, which with XS is hard ;) | ||
| plobsing | whiteknight: but do you need your text editor to run hyper-optimized code? | 21:06 | |
| whiteknight | if our performance is reasonable, if we offer lots of compiler frontends, offer good interoperability, and if we get embedded into everything, I think that's what we would call success | ||
| plobsing: no, but then again I hope Parrot has a better fate than just an medit plugin | |||
| plobsing: embedding is a way to expand, but it's not all Parrot can do | |||
| NotFound | whiteknight: a compiler can optimize its particular language and target parrot at the same time. | 21:07 | |
| plobsing | whiteknight: ELisp is nothing but an editor plugin, seems to be doing not too bad 20+ years on. | 21:08 | |
| whiteknight | NotFound: right. But once we get inside libparrot we lose a lot of the contextual information that could drive further optimizations. That is, anything the HLLs don't provide themselves we can't provide for them | ||
| plobsing: right, ELisp has it's niche and is doing well there. I don't see ELisp growing to take over the world though | 21:09 | ||
| If I don't use Emacs, I'm not going to use ELisp. no questions asked | |||
| lucian | i'm quite certain parrot languages will be suitably slow | ||
| NotFound | I have not much faith in the promises of dynamic optimizations. | ||
| whiteknight | if we offer a decent JIT, I think that's about the best we can do | 21:10 | |
| lucian | sure, many languages are doing fine with slow reference implementations | ||
| it's possible that yet another abstraction layer (parrot) can give the potential for other optimisations, especially across languages | 21:12 | ||
| but i'm not holding my breath | |||
| having ruby, python and perl6 call each other easily with reasonable speed would be enough | 21:13 | ||
| whiteknight: well, elisp is a crappy language in many ways | 21:14 | ||
| if elisp had been nicer and emacs had better platform integration, who knows | |||
| NotFound | (who (knows)) | 21:16 | |
| whiteknight | lucian: Parrot has a few things to offer, and we need to capitalize on them. We offer all the building blocks of any modern dynamic language, boxed and ready to go. We theoretically offer seamless interop between dynamic language | ||
| for a new compiler writer, it should be our job to make the choice of using Parrot as easy as possible | 21:17 | ||
| "I can write my own GC and my own exceptions system, or I can just use Parrot. Which do I choose?" | 21:18 | ||
| lucian | "or i can just use the JVM" | ||
| whiteknight | if the answer isn't "I'll just use Parrot", we're probably doing something wrong | ||
| shhh | |||
| atrodo | whiteknight> NIH is always the right answer ;) | ||
| dukeleto | whiteknight: how do we make the choice to use Parrot as easy as possible? | ||
| whiteknight | dukeleto: Great question. | ||
| NotFound | Don't force people to learn nqp X-) | ||
| lucian | NotFound: +1 | 21:19 | |
| ShaneC | ++ | ||
| atrodo | dukeleto> marketing | ||
| whiteknight | We need parrot to be available on many platforms. We need it to be pluggable into many other applications. We need to provide lots of features and provide them well | ||
| dukeleto | whiteknight: i think we need a web-interface to HLL-generation that has all the useful documentation nicely linked-to | ||
| whiteknight | documentation is definitely a big deal, especially since we're an unknown technology | ||
| atrodo | dukeleto++ great idea | ||
| dukeleto | whiteknight: we need to focus on actually making easy for a new HLL dev to grok parrot and start their language/project | ||
| lucian | i think the big missing bit is a blessed parrot system language | ||
| and random incremental improvement | 21:20 | ||
| dukeleto | lucian: yes, agree. What ever happened to Close ? | ||
| what happened to Austin_Hastings ? | |||
| NotFound | dukeleto: nothing. That's the problem. | ||
| dukeleto | seen Austin_Hastings | ||
|
21:20
Khisanth left
|
|||
| aloha | Sorry, I haven't seen Austin_Hastings. | 21:20 | |
| dukeleto | seen Austin_Hasting | ||
| aloha | Sorry, I haven't seen Austin_Hasting. | ||
| dukeleto | darn | ||
| seen Austin | 21:21 | ||
| aloha | Sorry, I haven't seen Austin. | ||
| whiteknight | lucian: I'm on the fence about that. On one hand, we do need a way to actually write code for Parrot. on the other hand, we would have to anoint one particular language for the job and that path leads to madness | ||
| That language is *clearly* not PIR | |||
| lucian | whiteknight: that's because PIR is silly | ||
| dukeleto | Rubinius solved this problem by not having it: You have to use Ruby. | ||
| lucian | high level and assembly don't go together | ||
| whiteknight | I use NQP for a lot of my work out of sheer momentum, but there's no real reason why it can't be NQP | ||
| NotFound | In my absolutely subjective view, the best language to write code for parrot is winxed. | 21:22 | |
| whiteknight | er, why it can't be Winxed | ||
| atrodo | But having one supported language makes the learning curve easier, even if there are alternatives | ||
| lucian | whiteknight: sure, sounds good. "bless" it | ||
| whiteknight | NotFound: I've considered rewriting Rosella in Winxed | ||
| I may try that with one of it's component libraries | |||
| NotFound | whiteknight: I'll be glad to help | ||
| plobsing | lucian: be careful what you wish for. if we get a "blessed" system language in Parrot, there's a good chance it might be NQP | ||
| or some variant thereof | 21:23 | ||
| whiteknight | A problem I have with NQP is that it uses P6object and it's ilk for everything, which makes interop with other "system" languages strained | ||
|
21:23
perlite_ joined
|
|||
| lucian | plobsing: meh, i don't hate perl syntax quite that much | 21:23 | |
| whiteknight: then i'd say nqp is unacceptable | |||
| the blessed language should have no runtime at all | 21:24 | ||
| plobsing | it isn't the perl syntax I take issue with, it's the leaning tower of abstraction | ||
| lucian | just a procedural wrapper over the native assembly | ||
| whiteknight | I find a lot of tasks that should be simple instead become difficult because I have to detect whether an object is a Class, a P6metaclass, a P6protoobject, or occasionally a NameSpace if the P6protoobject hasn't been initialized yet | ||
| lucian: I would agree with that. I keep coming back to the idea of C | |||
| C is a very small language by itself. Everything interesting is imported in libraries | 21:25 | ||
| lucian | whiteknight: yes, C (despite it's stupid syntax and lack of safety) is relatively nice | ||
| whiteknight | there is a reasonably-sized standard library, and huge external libraries | ||
| lucian: I'm not saying anything nice about C except that it is very small | |||
| lucian | at least the second is not a problem on parrop | ||
| NotFound | In some way winxed is to pir what C is to assembler. | 21:26 | |
| lucian | what i keep thinking of is that while concrete syntax matters (and perhaps too much to some people), it's not really so important | ||
| bacek_at_work | whiteknight, take a look at compilers/opsc/src/Ops/Compiler/Grammar.pm. It's almost full grammar for C :) | ||
| whiteknight | NotFound: I don't need the sales pitch. I really do like Winxed | ||
| lucian | abstract syntax and semantics can be as native parrot as possible | ||
| plobsing | NotFound: in some ways, yes. in others you've diverged (possibly because the PIR semantics are dead stupid) | ||
| but divergence is what it is | 21:27 | ||
|
21:27
perlite left
|
|||
| whiteknight | bacek_at_work: maybe we need to factor that out, or copy it to be a new C compiler on Parrot | 21:27 | |
|
21:27
perlite_ is now known as perlite
|
|||
| lucian | they way i'd like to see parrot is bytecode, 1:1 assembly for that and a system language on top | 21:27 | |
| whiteknight | lucian: exactly | ||
| Tene | A simple C frontend for PIR (or PBC) is certainly possible. | ||
| C-based grammar, that is. | |||
| whiteknight | a parrot bytecode, a simple assembler that was 1:1 with bytecode, and nothing else that libparrot understands directly | ||
| above that, we need HLLs to do everything else | 21:28 | ||
| Tene | NQC? | ||
| ;) | |||
|
21:28
Khisanth joined
|
|||
| NotFound | That was Close intention, wasn't it? | 21:28 | |
| whiteknight has to pack up and head home | |||
|
21:28
whiteknight left
|
|||
| plobsing | Tene: without objects, it would be pretty useless as a Parrot systems language. maybe minimal OO added to C, sort of like Obj-C. | 21:28 | |
| Tene | plobsing: 1) you could have a callmethod function, although that would suck. 2) Yeah, I was thinking of something like that, although I'm not very familiar with obj-c | 21:29 | |
| lucian | i'm not sure ObjC is a good ida | 21:30 | |
| idea | |||
| i like ooc's covers ooc-lang.org/ | |||
| Tene | plobsing: You'd need other extensions as well to interact with all of parrot, so it would always have variance from any specific language. | ||
| lucian | but NQC can just have a class keyword | ||
| like java, with both primitive types and objects | |||
| Tene | Any existing language is either going to have things we can't or dont' want to support in our impl (or without a runtime), or not have thigns that we need and so require extensions. | 21:32 | |
| cotto_work | That's funny. I was just toying with the idea of nqc last night. | ||
| Tene | Or both. | ||
| lucian | i think java is a good example because it's a system language for an OO vm | ||
| Tene | I rather like the idea of using a restricted/extended subset of an existing language, as long as it can be kept very simple, so C is a good choice. | 21:33 | |
| lucian | i guess few people will argue against C-style concrete syntax, since it's so ubiquitous | 21:34 | |
| plobsing | lucian: yes. sad, but true. | ||
| lucian | semantics should be highly inspired by parrot itself | 21:35 | |
| close really is close, and so is winxed | |||
| ShaneC | winxed is a javascript-alike, right? | ||
| lucian | ShaneC: vaguely | ||
| Tene | lucian: I'm probably insufficiently familiar with java to know what major syntactical diversions from C would be particularly suited for Parrot. | ||
| NotFound | ShaneC: is mostly based in javascript, but nothing but trivial examples is directly portable. | 21:36 | |
| Tene | One way we could start talking about this more would be to choose a small or medium sized PIR program and produce versions of it in hypothetical system languages. | ||
| lucian | Tene: no pointer syntax, object syntax, separate primitives | ||
| Tene | I'd expect to get a lot of value out of a prototyping stage like that. | 21:37 | |
| plobsing | ShaneC: check out Ωη;)XD to see my attempts to make a useful JS program a JS/Winxed polyglot. | ||
| ShaneC | something c-ish would be nice if you're targetting devs who may have implemented their language in c/c++ before | ||
| lucian | ShaneC: and parrot is written in C | ||
| i'm pretty sure you'll put people off with perl-ish concrete syntax | |||
| NotFound | Hypothetical languages has the advantage of no real world problems nor speed concerns. | 21:38 | |
| Tene | lucian: What do you mean specifically by "concrete syntax"? What other type of syntax is that distinguishing from? | ||
| lucian | Tene: well, there's concrete syntax (mostly tokens) and abstract syntax (an if statement is made of an expression and a body) | 21:39 | |
| Tene | lucian: Thanks; I was unfamiliar with those terms. | ||
| lucian is doing a module on formal definition of programming language | |||
| Tene | lucian: can you explain the "separate primitives" claimed advantage of using Java syntax? | 21:40 | |
| lucian | Tene: well, int is a primitive. Integer is a class, wrapping an int | ||
| parrot also has primitives and PMCs | |||
| Tene | lucian: I don't really see how the types available in real JAva implementations would influence our choice of using Java's syntax. | 21:41 | |
| NotFound | Winxed already does that. | ||
| lucian | Tene: i wasn't advocating java's syntax, just the idea of clear separation | ||
| NotFound: and yeah, that's nice | 21:42 | ||
| as i said, both close and winxed seem very good choices | |||
| close is dead, so that leaves winxed, or an evolution of it thereof | |||
| NotFound | int i = 1; /* $I register */ var i = 1; /* $P register initialized to 'Integer' PMC */ | ||
| lucian | NotFound: yeah, that looks good | 21:43 | |
| Tene | NotFound: exactly. | ||
| lucian | is there auto boxinng/unboxing? | ||
| plobsing | yep | ||
| NotFound | lucian: yes | ||
| lucian | cool | ||
| atrodo | winxed++ | ||
| Tene | NotFound: although, I'd probably s/var/pmc/ | 21:44 | |
| ShaneC | run any benchmarks on winxed? | ||
| NotFound | Tene: I tend to prefer familiar looking syntax. | ||
| lucian | i'm not really familiar with parrot or lorito plans, so i don't know if it's good as it is | ||
| Tene | NotFound: I tend to be skeptical of false cognates between similar languages. | 21:45 | |
| lucian | but it's certainly very close, so a fork/winxed 2.0 might be *the* system language | ||
| Tene: not really false, var is an object 'variable' | |||
| javascript doesn't really have variables, though | |||
| NotFound | I haven't yet found a confusion caused by that. | 21:47 | |
| lucian prefers var to pmc | |||
| anyway, this is concrete syntax | |||
| not *that* important | |||
| Tene | NotFound: also, depending on how thick or thin of a wrapper around pbc/pir we want, I wouldn't be surprised by int/str/num/pmc just defining registers, and a separate syntax for defining lexicals. | ||
| lucian | Tene: i think that sort of goes back to assembly for no good reason | 21:48 | |
| Tene | NotFound: One of the things people have complained about with NQP is repeated set/get/check-defined/autovivify of lexical symbols. | ||
| lucian | Tene: then maybe int, var and register? | ||
| NotFound | Tene: I have thinked about that, but for a now automatic lexicalization works well. | ||
| lucian | like C's register | ||
| Tene | lucian: Parrot has four types of registers, pmc/int/num/str | ||
| lucian | i know. by default lexical, register modifier: "register int a = 2" | 21:49 | |
| Tene | lucian: Ah. That's certainly feasible. | ||
| NotFound | Tene: actually lexicals are not repeatedly set/get unless you qualify them as volatile. | ||
| Tene | I'm certainly not arguing for anything here; just trying to explore the problem space. | ||
| NotFound | That works well if you are careful. | 21:50 | |
| Tene | NotFound: That would be a good solution too. | ||
| Possibly. | |||
| consider: { var i = 1; if true { i = 5; }; say(i}; } | 21:51 | ||
| plobsing | downwards-only lexicals do violate Principle Of Least Suprise, but are worth it because many cases work this way and it is much more efficient. | ||
| NotFound | You need the =: operator for that. | 21:52 | |
| Tene | iirc, in parrot right now using lexicals, that would print 1, unless you re-fetched the lexical before printing | ||
|
21:52
wknight-phone joined
|
|||
| plobsing | Tene: no. blocks aren't subs in winxed. | 21:52 | |
| Tene | Hmm. | 21:53 | |
| So, no lexical scope in inner blocks? | |||
| NotFound | var are lexicalized only if they are used in inner subs | ||
| lucian | NotFound: is there a tutorial/lang ref for winxed? | ||
| NotFound | lucian: no, I've been lazy on that. | ||
| Tene | no lexical scope for inner blocks would be a surprise for many programmers, although interestingly not a problem for python or ruby fans. | 21:54 | |
| plobsing | lucian: there are many examples in the repo. those are nifty. also there's the bootstrapped parser. | ||
| lucian | plobsing: i see | ||
| lucian is thinking of doing pynie-ng for gsoc | |||
| cotto_work | Tene: or php | 21:55 | |
| NotFound | The bootstrapped parser is not the best example, because it must deal with limitations of stage 0 | ||
| lucian | Tene: it's not a big deal, really | ||
| plobsing | Tene: variables are still scoped. | ||
| lucian | especially if you can request lexical scoping | ||
| plobsing | just not by the mechanism of subs | 21:56 | |
| registers get reused | |||
| lucian | i'm thinking of something like python3's nonlocal | ||
|
21:56
hercynium joined
|
|||
| Tene | plobsing: ahh, right, because you *wouldn't* be using parrot's lexicals there. | 21:57 | |
| plobsing: You'll run into problems with closures there, although it's certainly reasonable to have to ask for that explicitly. | |||
| plobsing | closures work fine. | 21:58 | |
| Tene | Hmm. | ||
| NotFound | Tene: winxed inner anonymous functions are closures, and auto lexicalize outer variables used. | ||
| plobsing | Ωη makes extensive use of closures. | 21:59 | |
| Tene | Okay; that sounds reasonable. | ||
|
21:59
lucian left,
lucian joined
|
|||
| plobsing | by default, closed-over variables only pass information downward. That is why you need volatile. | 21:59 | |
| wknight-phone | python-ng? | ||
| NotFound | Reciprocally, Ωη has driven the development and fixing of that features. | ||
| Tene | fwiw, although I don't consider this a serious suggestion, I rather like the idea of having several core languages that interoperate well. | 22:00 | |
| NotFound | I like that, too. | ||
| Tene | nqruby, nqpython, nqc, etc. | ||
| NotFound | But the advantage of winxed is that it does exists right no. | 22:01 | |
| now. | |||
| lucian | what id like to see is easily changeable concrete syntax | 22:02 | |
| for the system language | |||
| obviously its not necessary | |||
| Tene | lucian: explain "changeable"? | ||
| lucian | if i write pynie-ng it'll probably be in winxed | ||
| customisable | |||
| Tene | lucian: do you mean, individual programs would customize their own local syntax? | 22:03 | |
| lucian | so you can choose tokens (parens, braces, indentation-sensitive, etc.) | ||
| Tene | I'm skeptical about the value of that. | ||
| NotFound | It will probably be doable writing an alternate front end backed by winxed classes | 22:04 | |
| lucian | individual hlls would customise the concrete syntax of the system language | 22:05 | |
| so you dont need to write nqruby or nqpython | |||
| yeah, but it's not a big deal anyway | |||
| NotFound | Syntax matters for a lot of non-polylglot programmers. | 22:06 | |
| lucian | yes, and not only | 22:07 | |
| Tene | lucian: I'm skeptical that there's a useful minimal configuration space that you could use to specify python, javascript, scheme, C, php, java, etc. I would expect it to not be "close enough" for comfort for most of the languages people might want a language like, and I'd be skeptical about the utility of the other locations in the configuration space. | ||
| NotFound | I'd like to see some working general purpopse language written with Ωη | ||
| wknight-phone | ditto | 22:08 | |
| lucian | tene: it would not be close at all, semantically | ||
| Tene | lucian: Put differently, I'm skeptical that the syntaxes of the popular programming languages factor well. | ||
| The online presence of winxed leaves a lot to be desired; I'm checking out the repo now to get a better look at it. | 22:09 | ||
| lucian | i'm not sure either, but i'd like to try it | ||
| Tene | lucian: It's certainly an interesting experiment, I agree, and I'd be very curious to examine the results of that research. | 22:10 | |
| NotFound | At least I've surpassed winx club and full methal alchemist fans in google positioning X-) | ||
| lucian | i should probably look for papers on concrete syntax. i suspect there are few | 22:11 | |
| Tene | does winxed generate pir? pbc directly? pbc through POST? do we have POST->pbc yet? | ||
| NotFound | Tene: pir | ||
|
22:11
wknight-phone left
|
|||
| NotFound | Both stages generates pir | 22:12 | |
| Tene | One thing that hasn't been clear to me, do the people who object to NQP as a parrot systems language also object to use of PCT in the language impl? | 22:13 | |
| lucian | i strongly believe lang impls should be hosted on existing impls, if they exist | 22:14 | |
| NotFound | Tene: my main problem while deciding how to write winxed at its time was: lack of documentation and pct/nqp being a mobile target. | ||
| lucian | and the (minimal) rest in the parrot system language | 22:15 | |
|
22:15
ambs joined,
rurban_ joined
|
|||
| NotFound | Also, is easier to write pir directly that trying to figure what PAST you should generate to make it generate the pir you want. | 22:17 | |
| Tene | NotFound: One of the intended advantages of going through POST was that there's long been a plan for POST to bypass PIR and go straight to PBC. | 22:18 | |
| But, okay, that makes sense. | |||
| NotFound | Tene: you tell it. A *long* plan. | ||
|
22:19
rurban left
|
|||
| Tene | NotFound: Just like there's long been a plan to replace IMCC with "something" | 22:19 | |
| and to do language smoke reports | |||
|
22:19
rurban_ is now known as rurban
|
|||
| Tene | etc. | 22:19 | |
| NotFound | Tene: that plans were here before winxed even being imagined. Now winxed works and the plans are still on the way. | 22:20 | |
| Tene | NotFound: :) | ||
| NotFound | I like things that works. | ||
| Tene | Me too. | ||
| dukeleto | Tene: i am working on HLLs submitting smoke reports. But some people don't want smoke report emails to parrot-commits | 22:21 | |
| tadzik | hello | ||
| dukeleto | tadzik: greetings | ||
| cotto_work | We can set up a separate list if that annoys people. | 22:27 | |
| I can see how parrot-commits having that's not a commit would be undesirable. | |||
| NotFound | Or even several, for most active languages | ||
| cotto_work | -1. It should be easy to find out when a commit breaks something, no matter what it is. | 22:28 | |
| Tene | dukeleto: Sorry, I didn't mean to disparage your work or discourage you. I haven't updated my cache of "projects that get talked about but never happen" yet. | ||
| cotto_work | Tene: HLL smoking got upgraded from that list. ;) | 22:29 | |
| NotFound | Clearly marking the language in the subject should be enough to enable people to filter what they want. | ||
|
22:31
ambs left
|
|||
| Tene | Man, my time estimate skills are horribly useless lately. | 22:33 | |
|
22:34
lucian left
|
|||
| Tene | I just noticed that I had estimated that I could get a nqC, nqRuby, and nqPython compiler all implemented and interoperating over the next weekend. | 22:34 | |
| bacek_at_work | Tene, looks like you have veery long weekends :) | 22:35 | |
| NotFound | Tene: I got winxed stage 0 more or less useable in about a month. | ||
| Tene | bacek_at_work: I've been running into trouble with this at work lately. For the past week while working on this project, I've told my co-workers that I expect to finish that day, every day. | 22:37 | |
| NotFound | But my pir knowledge at that time was limited and I updated it on the way, should be doable a bit faster, | ||
| Tene | "Obviously all of the problems that I was having trouble dealing with yesterday will be absolutely trivial today somehow..." | ||
|
22:39
donaldh joined,
whiteknight joined
|
|||
| Tene | NotFound: thinking harder about it, if I adapt bacek's C grammar and emit PAST, it should be possible to get something working well over a long evening, judging by similar projects with PCT I've done in the past. | 22:40 | |
|
22:41
jan left
|
|||
| NotFound | I'm not sure about how well C syntax and parrot semantics will match. | 22:41 | |
| Tene | It seems like my default time estimation algorithm is using "time to understand and read a finished solution", and not thinking abotu the workinvolved to build and troubleshoot anything at all. | 22:42 | |
| NotFound | An attempt will help to understand the advantages and difficulties of that approach. | 22:43 | |
| whiteknight | Tene: if anybody has the mad skillz to accomplish that, it's you | 22:47 | |
|
22:49
Khisanth left,
cosimo joined
|
|||
| NotFound | megatokyo.com/strip/1161 | 22:52 | |
| Tene | Argh, I wish I wasn't so busy with work lately. | ||
| Really, I wish I could work full-time on Parrot. >.> | 22:53 | ||
|
22:53
Khisanth joined
|
|||
| dukeleto | Tene: well then, we should figure out how to accomplist that | 22:53 | |
| Tene: which involves making parrot usefult enough to a company that it would fund development | 22:54 | ||
| useful, even | |||
| Tene | dukeleto: If Parrot had piles of money, I would not put myself at the top of the list of devs to employ. | ||
| dukeleto | Tene: i am talking about a company funding work, not them giving a bunch of money to PaFo | 22:55 | |
| Tene | dukeleto: Sure. Same thing, though. I guess we can find out if/when that happens. | 22:56 | |
|
23:08
hercynium left
23:24
Andy left
23:56
donaldh left
|
|||