[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]Meeting Summary -- First Meeting 02-11-2002
From: |
Gopal V |
Subject: |
[DotGNU]Meeting Summary -- First Meeting 02-11-2002 |
Date: |
Sat, 2 Nov 2002 21:30:52 +0530 |
User-agent: |
Mutt/1.2.5i |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [DotGNU]Meeting Summary -- First Meeting 02-11-2002,
Gopal V <=