[DotGNU]Meeting Summary -- First Meeting 02-11-2002

[Gopal V]

IRC Meeting Summary
-------------------
        
        It's another week gone by , and a meeting as well. The IRC meeting
went normally with lots of discussion about things that don't matter
much... So this is more a report of 24 hours of IRC conversations than
a 2 hour window the meeting provides.. Also this is an oppurtunity to
reply to , or ask questions about the messages...

The room has been highly active during the weekend , and a number of
new questions and answers are coming up ... The topics vary from rhysw
talking about threading to chillywilly pretending to rms ... But let's
concentrate on the serious stuff for a while.... I'll leave the jokes
to people who read the logs for kicks ....

[01:36] t3rmin4t0r (address@hidden) joined #dotgnu.
[01:37] <t3rmin4t0r> hey all !
[01:37] <t3rmin4t0r> cscc compiled pnetlib verifies !!!!!
[01:38] <t3rmin4t0r> which means it's time for a release !!!
[01:38] <t3rmin4t0r> really !
***********************RELEASE******************************
[06:50] <t3rmin4t0r> anybody tested pnet today ?
[06:50] <t3rmin4t0r> well with the new patches to allow pnetlib ?
[06:51] <roberth> the silence is deafening...
[06:51] <t3rmin4t0r> "silence must be heard"
[06:52] <roberth> i'll update my cvs later today and take a look
[06:52] <roberth> um i mean "I'll cvs update later today.."
[06:52] <t3rmin4t0r> :-)
***********************Pnetlib active************************
[07:28] <manyoso> IMHO, (and I haven't looked at this) pinvoking the
                  existing C xml libraries is the best way to go
[07:28] <manyoso> this would likely need to be extended of course
[07:28] <t3rmin4t0r> manyoso: see dotgnu.xml in dotgnu-libs CVS for a 
                     wrapper on libxml2
[07:29] <t3rmin4t0r> not a compatible API , but works :-)
[07:29] <t3rmin4t0r> IMHO is a cleaner OO API
[07:29] <t3rmin4t0r> (coz I did it)
[07:29] Action: n1ko laughs
[07:29] <manyoso> ok, but could that be wrapped again to provide a System.Xml ?
[07:29] <t3rmin4t0r> well System.Xml requires a sequential access to Xml files
[07:30] <t3rmin4t0r> libxml2 uses a contruct tree and traverse model
[07:30] <t3rmin4t0r> which does not agree with XmlTextReader
.....
[07:31] <t3rmin4t0r> Kyeran: I managed to run XSharp examples using the new dll
......
[07:35] <t3rmin4t0r> so I'll take care of commiting that patch tonight
[07:35] <Kyeran> I should be able to finish up most of the other Get* funcs 
                 in directoy pretty fast now that the underlying C code is 
                 in place :)
[07:35] <t3rmin4t0r> giving me a clean sheet in savannah !
[07:35] <Kyeran> LOL :)
[07:35] <t3rmin4t0r> a clean sheet before a release is a good thing
[07:36] <Kyeran> Oh, when is the release??
[07:36] <t3rmin4t0r> rhys will be release pnet 0.4.6 on sunday
.....
[07:50] <Kyeran> Do we have any regexp functionallity in pnetlib yet???
[07:50] <n1ko> You got me
[07:51] <Kyeran> Hmm, that is something I really don't feel much like writing :)
[07:51] <n1ko> hehehe
[07:59] <n1ko> Anyone used ILExecThreadLookup* much? The documentation 
               seems to expect you to be familiar with the signature 
               format used with Java reflection....
[07:59] <Kyeran> Ahh, yes
[08:03] <n1ko> Yeah that's what I'm looking at...it doesn't help very much
[08:03] <Kyeran> Sorry
******************Must clarify that sometime****************************
[08:11] <n1ko> No, I'm using ILExecThreadNew to create an instance of 
               ThreadStateException, which uses ILExecThreadLookupMethod 
               to find the constructor
[08:12] <n1ko> t3rmin4t0r, Do you know where I can find an explanation of 
               the reflection signature lookup scheme, other than 
               "This is alot like Java's..."
......
[08:13] <n1ko> t3rmin4t0r, ThreadStartException:ThreadStartException ()
[08:14] <t3rmin4t0r> no args , right ?
[08:14] <t3rmin4t0r> :void ILExecThreadThrowSystem(ILExecThread *thread, 
                      const char *typeName
[08:14] <t3rmin4t0r> viz see throw.c
[08:14] <n1ko> t3rmin4t0r, Ah, thanks.
[08:15] <t3rmin4t0r> for throwing around "elephants"
[08:15] <n1ko> Yeah, I was adding ILExecThreadThrowThreadState, didn't see 
               that other method there...
..................
[08:41] <Kyeran> t3rmin4t0r:  Do you know if we have any regexp stuff in 
                 pnetlib yet?
[08:41] <t3rmin4t0r> nope , no regexp
[08:41] <t3rmin4t0r> atleast not in C#
[08:42] <t3rmin4t0r> could use regexp.h in the icalls
[08:42] <Kyeran> Ahhh, works for me :)
[08:42] <Kyeran> Unless you would rather regexp stuff be implemented in C#?
[08:43] <Kyeran> It is for pattern matching returned directoy names
[08:43] <t3rmin4t0r> well if we're going to implement System.RegularExpressions
[08:43] <t3rmin4t0r> but for the purpose
[08:43] <t3rmin4t0r> regexp.h works more than well enough
[08:43] <t3rmin4t0r> and would be faster as well ;-)
[08:43] <Kyeran> Cool, what I thought :)
[08:44] <t3rmin4t0r> both to implement and to run ...
[08:44] <t3rmin4t0r> Kyeran: pass along the pattern to the icall as a string
[08:44] <t3rmin4t0r> and there you have it
[08:44] <t3rmin4t0r> compile & match regexp in the icall
..................
[09:31] <Kyeran> Who Hoo, it worked!
[09:32] <Kyeran> Is regexp.h part of a system library or part of pnet????
***********************/usr/include/regexp.h*****************************
[18:19] <t3rmin4t0r> PInvoke == Platform Invoke == calling from .so
[18:19] <S11001001> Kyeran: yep
[18:19] <t3rmin4t0r> [DllImport("libc.so")]
[18:20] <t3rmin4t0r> public extern public void puts(String arg);
[18:20] <t3rmin4t0r> oops 2 publics ... but U get the idea
[18:20] <S11001001> t3rmin4t0r: how would it know to convert String to char*?
[18:20] <t3rmin4t0r> it is in the PInvoke marshalling rules
*******************************PInvoke***********************************
[20:53] Action: Rich333 hates floating point
[20:53] <Rich333> I have no idea how to do this float/double ToString stuff
[20:54] <Kyeran> sprintf
[20:54] <ajmitch> meeting's in a couple of hours :)
[20:54] <Rich333> t3: doesn't want to use sprintf
[20:54] <Kyeran> sprintf(buffer, "%d" thisNum)
******************************Float.ToString()**************************
[21:25] <Rich333> yay! ... sprintf's %g format is identical to c#'s g format
[21:27] <Kyeran> Thank Goodness for small favors eh :)
[21:39] <Rich333> Kyeran: how do you create an ILString (to pass back to C#)
                  from a regular C string?
[21:40] <Rich333> the icall I'm gonna have to write to get at sprintf will 
                  have to return a gc'd C# String
[21:40] <Kyeran> ILStringCreate(_thread, char *)
[21:41] <Rich333> thnx
[21:41] <Kyeran> NP
[21:41] <Rich333> that's garbage collection safe, right?
[21:41] <Rich333> ie, the returned ILString is gc'd
[21:44] <Kyeran> Well, as I understand it, it returns a pointer to an 
                 ILString which has been created in the engine
[21:44] <Kyeran> so yes, it should be gc safe
[21:44] <Rich333> k... thnx
[21:56] <minddog[ghp]> hrmm are all the IL* types in the ECMA spec for the CLI ?
[21:57] <Kyeran> You mean the reverse???
[21:57] <Kyeran> All the ECMA types are defined as IL*??
[21:57] <minddog[ghp]> are they?!
[21:57] <Kyeran> I know I add more when I need them
*********************Almost all Pnet types start with IL*****************
[22:46] rhysw (address@hidden) joined #dotgnu.
...
[22:47] <rhysw> reasonable - usual part-time work for trolltech, followed 
                by playing with treecc and stuff
[22:47] Action: rhysw is writing a modula-2 compiler to test treecc in a 
                new environment
[22:47] <ajmitch> yeah, i saw your treecc mail - the python stuff would be 
                  interesting for me
[22:47] <ajmitch> nice!
[22:48] Action: ajmitch likes python & is willing to do treecc stuff if time 
                arises :)
[22:48] <rhysw> that would be great
***************************gen_python.c ?*******************************
[22:55] <rhysw> minddog[ghp]: when playing with treecc, have you come 
                across anything frustrating?  I'm looking for ideas on 
                improving treecc for compiler construction.
.............
[22:56] Action: t3rmin4t0r been tangling with Float.ToString()
[22:56] <Rich333> / Formats a double using the %.<precision>g format in 
                    sprintf.
[22:56] <Rich333>       [MethodImpl(MethodImplOptions.InternalCall)]
[22:56] <Rich333>       extern public static String FormatReal(double d, int 
                    precision); <-- adding this to NumberFormatter.cs ok??
[22:56] <ajmitch> t3rmin4t0r: should have been in here, Rich333 & kyeran    
                  were discussing that stuff :)
[22:57] <t3rmin4t0r> Rich333: well I am struggling with IEEERemainder
[22:57] <t3rmin4t0r> it is returning -ve numbers
........
[22:57] <rhysw> sprintf -> ILStringCreate -> stop worrying about the problem
[22:58] Action: t3rmin4t0r thinks rhysw is going to go "a hack here , saves 
                nine there"
[22:58] <rhysw> no ... a 1 line sprintf will have less bugs than 1000 lines 
                of .cs code
[22:59] <rhysw> the I18N aspects can be handled with String.Replace.
[22:59] <Rich333> rhysw: should we have a direct icall interface to sprintf
                  (ie. string <icallname>(double d, string format))??
[23:01] <Rich333> rhysw: should we use snprintf instead? using sprintf 
                  could allow buffer overflows
[23:02] <rhysw> Rich333: in the "support" code, absolutely.  But keep in 
                mind that some platforms don't have snprintf.
[23:05] <Rich333> FormatDouble needs to do a lot of C# stuff beyond 
                  what sprintf provides... I was thinking FormatDouble 
                  and FormatSingle should both call on an icall and then 
                  handle the rest in C#
[23:05] <t3rmin4t0r> Rich333: for example you could get the basic 
                  fractions to C#
[23:05] <t3rmin4t0r> and add the stuff like signs, or I18n stuff later
............
[23:08] <rhysw> if the precision info is always passed in, then you can 
                use that to determine the likely maximum buffer size.
[23:08] <Rich333> rhysw: default precisions for floats are diff from doubles
[23:08] <Rich333> ah...
*******************LOOOOONG DISCUSSION ABOUT Floats********************
[23:14] <ajmitch> sigh, this should be a 30-sec decision ;)
[23:15] <t3rmin4t0r> ok ...
[23:15] <t3rmin4t0r> this is figured out ...
[23:15] <t3rmin4t0r> "sprintf" , and "safe"
[23:15] <t3rmin4t0r> if it satisfies both , good :-)
*************************WE FINALLY AGREEE****************************
[23:18] <Rich333> char * s = malloc(sizeof(char)*700);
[23:18] <Rich333>       sprintf(s,"%f",4.94065645841247e-324);
[23:18] <Rich333>       printf(s);
[23:19] <t3rmin4t0r> Rich333: epsilon can be printed only in the exponential 
                     model
[23:20] <t3rmin4t0r> sprintf is unsafe .. using snprintf
[23:20] <ajmitch> t3rmin4t0r: that a compile-time message, or your decision?
[23:20] <t3rmin4t0r> my decision
[23:20] <t3rmin4t0r> sprintf can overflow buffers
[23:20] <t3rmin4t0r> snprintf cannot
[23:21] <Rich333> snprintf is less portable
[23:21] <ajmitch> and it was said before that not all platforms have snprintf
[23:21] <t3rmin4t0r> Rich333: #ifdef
[23:21] <rhysw> and add to configure.in
*****************PARROT AND OTHER FUNNY FEATHERED FRIENDS****************
[23:31] <rhysw> your expression example is only testing int registers - 
                it isn't exercising the object parts of parrot
[23:31] <rhysw> the object stuff will be slower
[23:31] <t3rmin4t0r> :-)
[23:31] <t3rmin4t0r> still ...
[23:31] <t3rmin4t0r> I guess so ..
[23:32] <t3rmin4t0r> PerlHash model would a lot more slower
[23:32] <rhysw> absolutely - that's why I've kind of put it on hold for a 
                bit, to allow Dan, Leopold, etc, to figure out how Parrot 
                objects will work.  PerlHash's just won't cut it.
[23:33] Action: t3rmin4t0r wants Parrot ppl to get a peek into C# ...
[23:33] <ajmitch> i guess they'll appreciate having someone who has a 
                  compiler to target parrot, to tell them where parrot sucks
[23:33] <rhysw> in a nice way of course ... :)
[23:34] <t3rmin4t0r> I would have taken a shot at PMCodegen
[23:34] <t3rmin4t0r> but my design seems to crumble at the edges
[23:35] <rhysw> generating register code is annoying, because you have to 
                carry around more than "the value is on the top of the stack"
[23:35] <ajmitch> especially with a large number of registers
[23:35] <t3rmin4t0r> rhysw: which is why I say "imcc" loud and clear
[23:35] <rhysw> t3rmin4t0r: me too ... I started to write my own register 
                allocator and quickly ran away screaming
 .................
[23:37] <rhysw> the treecc nodes don't have tempVar's in them at present
                - use the return value from the "PMGenValue" operation 
                instead.  See "pm_output.h" for an example.
[23:39] <t3rmin4t0r> rhysw: I saw the PMRegister variable
[23:39] <rhysw> t3rmin4t0r: do you think that approach will work?
[23:40] <t3rmin4t0r> rhysw: only if PMRegister carries imcc variables 
                    (type+number)
[23:40] <rhysw> t3rmin4t0r: PMRegister refers to a "virtual imcc register", 
                not a Parrot register.
*********************************THREADING RISES UP********************
[23:43] Action: t3rmin4t0r wants more info from rhysw about Threading
[23:44] Action: rhysw wants more info about threading from someone so he 
                has it to provide to gopal
[23:44] <rhysw> what do you want to know about threading?
[23:44] <t3rmin4t0r> rhysw: what all is left to implement in threading ?
[23:45] <t3rmin4t0r> I know the support code works
[23:45] <t3rmin4t0r> does thread support need a complete makeover ?
[23:46] <rhysw> Some work is still needed on monitors and wait handles 
                in the support code, but it is otherwise OK.  The real 
                problem is the engine - a lot of locks need to be put 
                around critical structures to protect them from 
                simultaneous access.  And then "lib_thread.c" needs to 
                call support where appropriate.
[23:47] <t3rmin4t0r> gimme an example on a lock needed ?
[23:47] <rhysw> give me a sec ..
[23:48] <rhysw> pretty much all of lib_reflect.c, lib_type.c, etc, needs to 
                acquire the metadata lock when doing reflection operations
[23:50] <rhysw> for reference, the metadata locking macros are in 
                "engine.h", down the bottom
[23:51] <rhysw> also, anything that touches the ILExecThread or ILExecProcess
                structures may potentionally need a lock (the main exception
                to this is the CVM value stack, which is only accessed by 
                its own thread).
[23:55] <rhysw> implement the thread create primitives in lib_thread.c, 
                call them and watch the core dumps.  That's all I can 
                suggest at this point.
[23:55] <t3rmin4t0r> ok .. I think n1ko might have better questions
***************************GCC AND TREECC****************************
[00:15] <rhysw> been messing with building a modula-2 compiler based 
                around treecc.  No pnet code.  Plain C, with the goal 
                of plugging it onto the front of gcc eventually.
[00:15] <rhysw> right now, it spits out C code, to be fed into gcc directly.
[00:15] <ajmitch> great
[00:16] <rhysw> eventually, it will generate gcc trees and be statically linked
[00:16] <ajmitch> so you're trying for a new gcc frontend, using treecc?
[00:16] <rhysw> I'm using this as a test bed to get back into treecc 
                development at bit.  There have been some things that 
                have frustrated me about treecc and now seems a good 
                time to address them.
[00:17] <t3rmin4t0r> springjp has been talking about strategy objects in treecc
[00:17] <rhysw> ajmitch: yes - 2 things will come out of it - a modula-2 
                front-end, and a generic set of treecc definitions to help 
                other front-end writers abstract the icky gcc details.
************************ASPECT ORIENTED PROGRAMMING*******************          
[00:37] <rhysw> AOP == OOP broken up into separate little pieces that 
                the compiler puts back together
[00:37] <t3rmin4t0r> AOP == Shatter your brain and let the compiler glue
                     the peices
-- 
The difference between insanity and genius is measured by success