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