On Wed, Dec 22, 2004 at 01:29:26AM -0700, Clint Jeffery wrote: > If you are referring to the Unicon trap() function, the C-calling-Icon > interface that it uses is not yet supported under iconc. The current > code in rposix.r has a lot of VM-specific statements. Devising an > iconc version might or might not be straightforward, but someone would > have to understand iconc's code generation model in order to undertake it.
OK, I will look into this myself then. But, don't expect much, as I started using and hacking (un)Icon less than a month ago... > > I do expect to have a lot of work done on iconc in 2005, completing a port > to MS Windows and extending iconc to better support unicon's extended > features. trap() is not yet on my agenda but would fit under that general > scope. I would welcome assistance or support of any kind for that effort, > for example an iconc implementation of the C-calling-Icon interface would be > a big help. There may be issues e.g. with type inferencing. After updating > Iconc to better support Unicon I hope to resume work on optimizing its > generated code. Do you think it worthwhile to aim for .Net compatibility, as well as native C? We seem to already have JVM version, and what I see in the M$ world is more and more of .Net. OSS seems to take this on, see projects such as dotgnu and mono. I think usage of un(Icon) can improve considerably if it can interoperate with .Net (this will also save us from programming in C#;-), certainly in Windos environment... > > Clint > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
