From dragisha at m3w.org Fri Apr 6 21:38:30 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 6 Apr 2012 21:38:30 +0200 Subject: [M3devel] cm3ide, ESC, cm3jvm(?) Message-ID: <1DDF651B-C60C-45A3-8DF4-005216FE67ED@m3w.org> Recently I found time to get cm3ide up? My thanks to Bill, Farshad, Randy and Olaf! Also, I see there is ESC now in cm3 /... Can we expect complete version, or do we already have that? How to use? Also II - is there any chance to get cmass JVM opensourced? I have many ideas how to make that useful.. TIA, dd From dabenavidesd at yahoo.es Fri Apr 6 22:43:35 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 6 Apr 2012 21:43:35 +0100 (BST) Subject: [M3devel] cm3ide, ESC, cm3jvm(?) In-Reply-To: <1DDF651B-C60C-45A3-8DF4-005216FE67ED@m3w.org> Message-ID: <1333745015.46036.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: nice idea, JVM + CMM3 is nice product. ESC was a nice idea too, but if you see its results in Java I don't know if it has been a "market" success (lost type checking information can make a better realization of it, like in casting errors, etc), although it was not intended for that but to be useful in the research area of CS, specially education. I would like the idea of using typed interpretation of objects on it for Modular checking of other jvm mechanics (though Java Object Model is inherently different from that of a Module-oriented VM, but since it's almost an operating system): for instance a new type-safe object make of Objects, but in that sense, you have (mandatory) to be sound to tough compiler purists specially in Java attempt that but still not quite like Modula-3 Module semantics purity. So it's hard to talk and hard technology to crasp on, but sure, none of them will be disliked by such a beast, anyone agree? Thanks in advance --- El vie, 6/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] cm3ide, ESC, cm3jvm(?) > Para: "m3devel" > Fecha: viernes, 6 de abril, 2012 14:38 > Recently I found time to get cm3ide > up? My thanks to Bill, Farshad, Randy and Olaf! > > Also, I see there is ESC now in cm3 /... Can we expect > complete version, or do we already have that? How to use? > > Also II - is there any chance to get cmass JVM opensourced? > I have many ideas how to make that useful.. > > TIA, > dd > > From dabenavidesd at yahoo.es Thu Apr 12 23:09:00 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 12 Apr 2012 22:09:00 +0100 (BST) Subject: [M3devel] A Baby Modula-3 Operating Environment hosted on SPIN OS for Language Researchers Message-ID: <1334264940.21694.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I was reading about Meta-Environments (and finding some sort of it for Modula-3) and found MetaBETA (Scandinavian school OO programming language), that uses Dynamic linking and loading of SPIN mechanism for itself: http://www.daimi.au.dk/PB/506/PB-506.pdf Can't we make our own flavor for it? Meta-BM3. We could create the drivers needed for it in a Modula-3 fashion (actually as it happens the side effects of UNSAFE modules could be verified by dynamic type tests and/or verified assembly like in a JVM-style ?-code not to corrupt the verified ones) or by memory watchdog as I believe Alpha architecture had a nice feature to warn against unwanted access on certain memory regions, hadn't it? Thanks in advance From penn43 at gmx.com Thu Apr 19 00:10:24 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Thu, 19 Apr 2012 00:10:24 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120418221024.27330@gmx.com> Dear Modula-3 developers, I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. I hope you can help me clarify some points and dispel some doubts. The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. I thank you in advance. Best regards, Marresh P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). From rcolebur at SCIRES.COM Thu Apr 19 01:13:26 2012 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 18 Apr 2012 19:13:26 -0400 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: Marresh: I've programmed in a number of different languages. For me, I've found that Modula-3 is the best for most of what I do. Further, I've found that the concepts in Modula-3 help you think through things in a more complete manner, thereby making you a better programmer. When I've been forced to use other languages, I've often found myself starting out in Modula-3 and then translating to the other language once the main concepts are defined. Just because Modula-3 is touted as a systems programming language doesn't mean it is too complex for simpler projects; however, if you are only wanting to write very simple, independent programs that won't ever have any parts reused anywhere else, you may find the initial discipline of interfaces and implementations a bit verbose. The language itself is really quite compact, given its power, and the concepts are straightforward and don't throw you curve balls. I can't really comment much about Oberon as I haven't used it much. As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. I'm not sure if anyone has done any recent bindings to GUI toolkits. Hope this helps. --Randy Coleburn -----Original Message----- From: penn43 at gmx.com [mailto:penn43 at gmx.com] Sent: Wednesday, April 18, 2012 6:10 PM To: m3devel at elegosoft.com Subject: [M3devel] Modula-3 questions Dear Modula-3 developers, I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. I hope you can help me clarify some points and dispel some doubts. The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. I thank you in advance. Best regards, Marresh P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). From mika at async.caltech.edu Thu Apr 19 02:25:50 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 18 Apr 2012 17:25:50 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: <20120419002550.798361A205B@async.async.caltech.edu> penn43 at gmx.com writes: ... >P.S. is the creation and maintenance of module interfaces all that trouble? I >read somewhere that it is a pain, and that the inconvenience of it would only >be paid off when one has to manage large projects (which is not my case). I personally find the Modula-3 interface design to be one of the best parts of the language. It would maybe be nice if it had more levels of qualification, like Java, but that's a minor issue. The way that it's almost impossible to get name clashes is a much bigger advantage. And you find that the small effort required to type your procedure prototypes pays off rather quickly... Finally, I could ask you what kind of programming you intend to do that you are certain won't eventually turn into large projects :-) Mika From dabenavidesd at yahoo.es Thu Apr 19 03:52:27 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 02:52:27 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> Message-ID: <1334800347.21677.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Threads are common use of Modula-3 Standard Interfaces because basically Modula-3 was born in Modula-2+ programming environments of multi-processor or mainframes (it was a kind of ahead of its time for real). If you don't need Thread I guess you don't want to use several options like OS support (like Systems programming) and stuff, Modula-3 has its own environment for safe-threads (embedded) threads, though its use is not mandatory and not successful in any SMP environment (by default nowadays). GUIs are not mandatory supported and constructed bottom up, if you want a new GUI system, you want a threaded one (that's Modula-2+ supposition since, you want not much overhead so be alerted in any event or for stronger distributed multi-window system like current Trestle is designed). In any event, there is a KDevelop project of Modula-3 but that was quite some time ago. Though there is some support in Gtk, but again talking about a small size project that is overkilling, Gtk library dependencies on C makes a not want to develop for them, so avoid them right? Simple languages are characterized by the smaller language definitions, this the case with C++, C, Java (the last two are called 'simple'), but spirit of Oberon was the same foundation of Modula-3, simpler is better, cleaner and still good support for better programming productivity (say Oberon for ?-controllers and small-footprint environments) so it gets rid of everything it can be too onerous (including big libraries and etc, but this days libraries and smaller memories are bigger than those days, so) Also Oberon was designed for compiler designer, so you do the math. Thanks in advance --- El mi?, 18/4/12, penn43 at gmx.com escribi?: > De: penn43 at gmx.com > Asunto: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 18 de abril, 2012 17:10 > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. > I have already had a look at the language, and it certainly > looks interesting. However, I still have some misgivings > about starting learning Modula-3, since it would be a > considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some > doubts. > > The first point is that I would neither be working on large > projects, nor doing systems programming. I understand these > were the two major strengths of Modula-3, but neither would > be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > Secondly, could you please help me understand what are the > reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > So, again, keeping in mind that I don't need the advanced > features mentioned above, nor multithreading, does it make > any sense for me to choose Modula-3 instead of Oberon, or > Object Pascal? > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces > all that trouble? I read somewhere that it is a pain, and > that the inconvenience of it would only be paid off when one > has to manage large projects (which is not my case). > > From dragisha at m3w.org Thu Apr 19 10:36:56 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Apr 2012 10:36:56 +0200 Subject: [M3devel] Modula-3 questions In-Reply-To: References: <20120418221024.27330@gmx.com> Message-ID: <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> Maybe of interest to original poster - Modula-3 development tools are extremely lightweight and compact. Easy to create and maintain any project, be it small or not. And portable to extreme. On Apr 19, 2012, at 1:13 AM, Coleburn, Randy wrote: > As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." This is new one to me, but - in the best Modula-3 tradition - it will be reused a lot :). > > WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. Not least of these being concepts borrowed from C++ :) > > I'm not sure if anyone has done any recent bindings to GUI toolkits. I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Apr 19 16:10:29 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:10:29 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> References: <20120418221024.27330@gmx.com> <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> Message-ID: <4F901CD5.9050405@lcwb.coop> On 04/19/2012 03:36 AM, Dragi?a Duri? wrote: > Maybe of interest to original poster - Modula-3 development tools are extremely lightweight and compact. Easy to create and maintain any project, be it small or not. And portable to extreme. > > On Apr 19, 2012, at 1:13 AM, Coleburn, Randy wrote: > >> As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." > > This is new one to me, but - in the best Modula-3 tradition - it will be reused a lot :). > >> >> WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. > > Not least of these being concepts borrowed from C++ :) > >> >> I'm not sure if anyone has done any recent bindings to GUI toolkits. > > I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. I would be interested in this binding. From rodney_bates at lcwb.coop Thu Apr 19 16:54:06 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:54:06 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: References: <20120418221024.27330@gmx.com> Message-ID: <4F90270E.5030702@lcwb.coop> On 04/18/2012 06:13 PM, Coleburn, Randy wrote: > Marresh: > > I've programmed in a number of different languages. > > For me, I've found that Modula-3 is the best for most of what I do. > > Further, I've found that the concepts in Modula-3 help you think through things in a more complete manner, thereby making you a better programmer. > > When I've been forced to use other languages, I've often found myself starting out in Modula-3 and then translating to the other language once the main concepts are defined. > > Just because Modula-3 is touted as a systems programming language doesn't mean it is too complex for simpler projects; however, if you are only wanting to write very simple, independent programs that won't ever have any parts reused anywhere else, you may find the initial discipline of interfaces and implementations a bit verbose. > > The language itself is really quite compact, given its power, and the concepts are straightforward and don't throw you curve balls. > > I can't really comment much about Oberon as I haven't used it much. > > As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." > I don't really believe this, for several reasons. C++ does add some things that make it harder. For example, you can use library (library is not language, BTW) versions of arrays, at the usual costs of heap-allocation, sometimes unnecessary. But it only works if you use it. If you do an array-bounds thing, you can blow your leg off just as badly in C as in C++. C++ preserves C's broken half-treatment of arrays, with the same possibilities for these bugs. Meanwhile, C++ adds a lot of additional ways to shoot yourself in the foot. For example, the user-defined overloading system means you can add a function declaration and have existing calls silently switch from whatever function they used to call to your new one. Or the reverse. Deleting a declaration could result in existing calls on it silently switching to some other function, instead of giving compile errors, as you would expect. A nightmare if the code is anything but small. > WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. > > I'm not sure if anyone has done any recent bindings to GUI toolkits. > > Hope this helps. > > --Randy Coleburn > > > -----Original Message----- > From: penn43 at gmx.com [mailto:penn43 at gmx.com] > Sent: Wednesday, April 18, 2012 6:10 PM > To: m3devel at elegosoft.com > Subject: [M3devel] Modula-3 questions > > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some doubts. > > The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? > > Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. > So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? > > Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). > From rodney_bates at lcwb.coop Thu Apr 19 17:02:27 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 10:02:27 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120419002550.798361A205B@async.async.caltech.edu> References: <20120418221024.27330@gmx.com> <20120419002550.798361A205B@async.async.caltech.edu> Message-ID: <4F902903.8060807@lcwb.coop> On 04/18/2012 07:25 PM, Mika Nystrom wrote: > penn43 at gmx.com writes: > ... >> P.S. is the creation and maintenance of module interfaces all that trouble? I >> read somewhere that it is a pain, and that the inconvenience of it would only >> be paid off when one has to manage large projects (which is not my case). > > I personally find the Modula-3 interface design to be one of the best > parts of the language. It would maybe be nice if it had more levels of > qualification, like Java, but that's a minor issue. The way that it's > almost impossible to get name clashes is a much bigger advantage. The Java levels-of-qualification system is not at all what it looks like at first glance. Semantically, it's no more than a flat space, with names of things allowed to have dots in them (and no doubt white space and comments around the dots.) A.B has no more relation to A.C than Shooby_Do_Bop has to HeyDownHoDownDerryDerryDown. Yeah, I know it does reflect where the source files are located in your directory structure, but aside from having no semantic significance, that's only a cultural convention. The language explicitly permits implementors to search for source files otherwise. > > And you find that the small effort required to type your procedure > prototypes pays off rather quickly... > > Finally, I could ask you what kind of programming you intend to do that > you are certain won't eventually turn into large projects :-) > > Mika > From rodney_bates at lcwb.coop Thu Apr 19 16:45:53 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:45:53 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: <4F902521.8000105@lcwb.coop> On 04/18/2012 05:10 PM, penn43 at gmx.com wrote: > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some doubts. > > The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? > C++ is 6 times more complicated than Modula-3, by reference manual page count, which is usually a reasonable, simple way to estimate complexity. Java is 8 times, though its reference manual is significantly less dense than most. Ada is 10 times. With room for some minor quibbles, Modula-3 has more useful programming features than any of these, thus the best "economy of concept", or ratio of real power to complexity. Java is especially low on this scale, since it is quite feeble, yet has an enormous reference manual. Particularly, all array- and record-like constructs are forcibly heap allocated whether you need it or not, with resulting coding overhead. You always have to allocate and either constantly NIL-check or create an argument in your head/comments that they are always non-NIL. This is usually scattered around your code. Unnecessary heap-allocation has execution space and time overhead too, but this would probably not be of concern to you. Modula-3 is also particularly good at minimizing interactions among language features. This makes it easier to learn/use a subset of the language, with less risk of tripping over something you haven't studied. That happens a _lot_ in C++ and Ada. If you ever eventually want to use more features, they are there, without having to relearn the superficial syntax, etc., of the basic stuff. > Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. > So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? > If you prefer absolute minimal language complexity without regard for programming richness, as opposed to economy of concept, the Oberon family fares better by that criterion. But I think, even with your minimal goals, you will like some of the additional things Modula-3 has. > Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). > > From dabenavidesd at yahoo.es Thu Apr 19 18:30:36 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 17:30:36 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <4F902521.8000105@lcwb.coop> Message-ID: <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I think is a good comparison to say C++ is to Java what Modula-3 is to Oberon. The typing model is similarly relatively augmented from one to the other and UNSAFE features are allowed in the former without control over it (where is in Modula-3 is more confined to UNSAFE MODULEs). Also a machine independent code is not so in the object-code sense (though Modula-3 has its own scripting extension engine). Modula-3 OBJECT TYPEs are relative number ordered but other Record-Oriented languages may have a rather distinct type classification system. C++ just makes the multiple-inheritance support system a big headache for every programmer accustomed to handle single-inheritance languages, but not counter wise case In easy of use Modula-3 hands its own distinct picture of program in terms of Modules (which handle software re usability stronger than just Object-type systems). Object Oberon instead focuses on that counter-idea. C++ is a lot like Java in the Class-word sense, which is hard to deal with when you don't have explicit INTERFACE TYPEs like Modula-3 ones (you can create object from OBJECTs their selves and INTERFACES TYPEs), Java still makes an emulation via interfaces but are not just for abstract classes, and not all kind of classes (if you don't program in that way), and you sort to adhere to that or leave it. Modula-3 modularity is more uniform from that. C++ has the template mechanism but it isn't that well designated to be a GENERIC TYPE but some sort of template of code of untyped code. This can be powerful if you want to have polymorphism but you can have a hard type figuring out what kind of template class you want in any case. This is a Modula-3 advantage since most of the type system developed after them are really oriented towards controlling that complexity via Compile-type checking (which still can make the case for a Extended-Type Checker concept) Thanks in advance --- El jue, 19/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 09:45 > > > On 04/18/2012 05:10 PM, penn43 at gmx.com > wrote: > > Dear Modula-3 developers, > > > > I am not a Modula-3 user, but I am considering becoming > one. I have already had a look at the language, and it > certainly looks interesting. However, I still have some > misgivings about starting learning Modula-3, since it would > be a considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > > I hope you can help me clarify some points and dispel > some doubts. > > > > The first point is that I would neither be working on > large projects, nor doing systems programming. I understand > these were the two major strengths of Modula-3, but neither > would be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > > > C++ is 6 times more complicated than Modula-3, by reference > manual page count, which is > usually a reasonable, simple way to estimate > complexity. Java is 8 times, though its > reference manual is significantly less dense than > most. Ada is 10 times. With room > for some minor quibbles, Modula-3 has more useful > programming features than any of these, > thus the best "economy of concept", or ratio of real power > to complexity. > > Java is especially low on this scale, since it is quite > feeble, yet has an enormous > reference manual. Particularly, all array- and > record-like constructs are forcibly heap > allocated whether you need it or not, with resulting coding > overhead. You always have > to allocate and either constantly NIL-check or create an > argument in your head/comments > that they are always non-NIL. This is usually > scattered around your code. Unnecessary > heap-allocation has execution space and time overhead too, > but this would probably not > be of concern to you. > > Modula-3 is also particularly good at minimizing > interactions among language features. > This makes it easier to learn/use a subset of the language, > with less risk of tripping > over something you haven't studied. That happens a > _lot_ in C++ and Ada. If you ever > eventually want to use more features, they are there, > without having to relearn the > superficial syntax, etc., of the basic stuff. > > > Secondly, could you please help me understand what are > the reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > > So, again, keeping in mind that I don't need the > advanced features mentioned above, nor multithreading, does > it make any sense for me to choose Modula-3 instead of > Oberon, or Object Pascal? > > > > If you prefer absolute minimal language complexity without > regard for programming richness, > as opposed to economy of concept, the Oberon family fares > better by that criterion. But I > think, even with your minimal goals, you will like some of > the additional things Modula-3 has. > > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > > > I thank you in advance. > > > > Best regards, > > > > Marresh > > > > P.S. is the creation and maintenance of module > interfaces all that trouble? I read somewhere that it is a > pain, and that the inconvenience of it would only be paid > off when one has to manage large projects (which is not my > case). > > > > > From microcode at zoho.com Thu Apr 19 18:51:29 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Thu, 19 Apr 2012 16:51:29 +0000 Subject: [M3devel] Fw: Modula-3 questions Message-ID: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> I sent this to Alejandro by mistake. It should have gone to the list. Sorry guys. -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. -----Original Message----- From: "Daniel Alejandro Benavides D." Date: Thu, 19 Apr 2012 17:30:36 To: ; Rodney M. Bates Subject: Re: [M3devel] Modula-3 questions Hi all: I think is a good comparison to say C++ is to Java what Modula-3 is to Oberon. The typing model is similarly relatively augmented from one to the other and UNSAFE features are allowed in the former without control over it (where is in Modula-3 is more confined to UNSAFE MODULEs). Also a machine independent code is not so in the object-code sense (though Modula-3 has its own scripting extension engine). Modula-3 OBJECT TYPEs are relative number ordered but other Record-Oriented languages may have a rather distinct type classification system. C++ just makes the multiple-inheritance support system a big headache for every programmer accustomed to handle single-inheritance languages, but not counter wise case In easy of use Modula-3 hands its own distinct picture of program in terms of Modules (which handle software re usability stronger than just Object-type systems). Object Oberon instead focuses on that counter-idea. C++ is a lot like Java in the Class-word sense, which is hard to deal with when you don't have explicit INTERFACE TYPEs like Modula-3 ones (you can create object from OBJECTs their selves and INTERFACES TYPEs), Java still makes an emulation via interfaces but are not just for abstract classes, and not all kind of classes (if you don't program in that way), and you sort to adhere to that or leave it. Modula-3 modularity is more uniform from that. C++ has the template mechanism but it isn't that well designated to be a GENERIC TYPE but some sort of template of code of untyped code. This can be powerful if you want to have polymorphism but you can have a hard type figuring out what kind of template class you want in any case. This is a Modula-3 advantage since most of the type system developed after them are really oriented towards controlling that complexity via Compile-type checking (which still can make the case for a Extended-Type Checker concept) Thanks in advance --- El jue, 19/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 09:45 > > > On 04/18/2012 05:10 PM, penn43 at gmx.com > wrote: > > Dear Modula-3 developers, > > > > I am not a Modula-3 user, but I am considering becoming > one. I have already had a look at the language, and it > certainly looks interesting. However, I still have some > misgivings about starting learning Modula-3, since it would > be a considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > > I hope you can help me clarify some points and dispel > some doubts. > > > > The first point is that I would neither be working on > large projects, nor doing systems programming. I understand > these were the two major strengths of Modula-3, but neither > would be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > > > C++ is 6 times more complicated than Modula-3, by reference > manual page count, which is > usually a reasonable, simple way to estimate > complexity. Java is 8 times, though its > reference manual is significantly less dense than > most. Ada is 10 times. With room > for some minor quibbles, Modula-3 has more useful > programming features than any of these, > thus the best "economy of concept", or ratio of real power > to complexity. > > Java is especially low on this scale, since it is quite > feeble, yet has an enormous > reference manual. Particularly, all array- and > record-like constructs are forcibly heap > allocated whether you need it or not, with resulting coding > overhead. You always have > to allocate and either constantly NIL-check or create an > argument in your head/comments > that they are always non-NIL. This is usually > scattered around your code. Unnecessary > heap-allocation has execution space and time overhead too, > but this would probably not > be of concern to you. > > Modula-3 is also particularly good at minimizing > interactions among language features. > This makes it easier to learn/use a subset of the language, > with less risk of tripping > over something you haven't studied. That happens a > _lot_ in C++ and Ada. If you ever > eventually want to use more features, they are there, > without having to relearn the > superficial syntax, etc., of the basic stuff. > > > Secondly, could you please help me understand what are > the reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > > So, again, keeping in mind that I don't need the > advanced features mentioned above, nor multithreading, does > it make any sense for me to choose Modula-3 instead of > Oberon, or Object Pascal? > > > > If you prefer absolute minimal language complexity without > regard for programming richness, > as opposed to economy of concept, the Oberon family fares > better by that criterion. But I > think, even with your minimal goals, you will like some of > the additional things Modula-3 has. > > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > > > I thank you in advance. > > > > Best regards, > > > > Marresh > > > > P.S. is the creation and maintenance of module > interfaces all that trouble? I read somewhere that it is a > pain, and that the inconvenience of it would only be paid > off when one has to manage large projects (which is not my > case). > > > > > From mika at async.caltech.edu Thu Apr 19 19:29:18 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 19 Apr 2012 10:29:18 -0700 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> References: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> Message-ID: <20120419172918.A32A91A205B@async.async.caltech.edu> But at the same time the Green Book (G. Nelson, ed., Systems Programming with Modula-3, Prentice-Hall 1991) is probably the best description of how to actually use object-oriented programming in practice that's ever been published... I once wrote to whoever now owns Prentice-Hall and asked their copyright clearance person for permission to photocopy chapters of that book for a class I was teaching. No response, not even "absolutely not." But most of it (all of it??) is available online. I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that if the hordes discover it, they will ruin it. One LONGINT is enough headaches for me. I find the unchanging nature of the language to be a huge advantage in what I do. Mika -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. From dknoto at next.com.pl Thu Apr 19 19:38:45 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Thu, 19 Apr 2012 19:38:45 +0200 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419172918.A32A91A205B@async.async.caltech.edu> References: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> <20120419172918.A32A91A205B@async.async.caltech.edu> Message-ID: <20120419193845.7206cc1e@wenus.next.com.pl> Dnia 2012-04-19, o godz. 10:29:18 Mika Nystrom napisa?(a): > > But at the same time the Green Book (G. Nelson, ed., Systems Programming > with Modula-3, Prentice-Hall 1991) is probably the best description of > how to actually use object-oriented programming in practice that's ever > been published... > It is a pity that Amazon does not send used books outside the U.S., the seller on eBay too. Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Thu Apr 19 20:00:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 19:00:25 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419172918.A32A91A205B@async.async.caltech.edu> Message-ID: <1334858425.89359.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: In terms of literature I believe by the long lapsus of history that has gone after that book, you don't need to understand much of it to notice that some people don't realize the language as of tremendous historic value, aided by negligent community outside. BTW Python it's one of the few that recognize its strong influence over it. But talking about history and then what happened, this matcvhes with what we are seeing: "Conferences, on how to program Object Oriented Programming"; my goodness, this is the Modula-3 history, what else are they looking for? Thanks in advance --- El jue, 19/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: microcode at zoho.com > CC: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 12:29 > > But at the same time the Green Book (G. Nelson, ed., Systems > Programming > with Modula-3, Prentice-Hall 1991) is probably the best > description of > how to actually use object-oriented programming in practice > that's ever > been published... > > I once wrote to whoever now owns Prentice-Hall and asked > their copyright > clearance person for permission to photocopy chapters of > that book > for a class I was teaching. No response, not even > "absolutely not." > But most of it (all of it??) is available online. > > I'm somewhat ambivalent about marketing Modula-3 too > hard. I fear that > if the hordes discover it, they will ruin it. One > LONGINT is enough > headaches for me. I find the unchanging nature of the > language to be > a huge advantage in what I do. > > Mika > > -----Original Message----- > From: microcode at zoho.com > Date: Thu, 19 Apr 2012 16:49:57 > To: Daniel Alejandro Benavides D. > Reply-To: microcode at zoho.com > Subject: Re: [M3devel] Modula-3 questions > > A big inhibitor to Modula-3 is the lack of books and > tutorials. CM3 has a great system running on tons of > platforms. But where can people learn to code Modula-3? > > I see this as the biggest obstacle. > > > From dabenavidesd at yahoo.es Thu Apr 19 21:20:54 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 20:20:54 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419193845.7206cc1e@wenus.next.com.pl> Message-ID: <1334863254.51331.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: In my native country (Colombia/South America) there isn't problem about redistributing copyrighted material provided that it is not for profit purposes. Or having acquirement rule in EU countries, (though the aftermath of Trading agreements might overcome that as well) might facilitate photocopies or microfilm distribution. In any case it will need some sort of Modula-3 foundation or something to validate the use of that material I guess. I like the idea of having it to use over Internet for instance in Amazon, etc, but I guess lobbying would be required. Having said that, DEC-SRC building in Palo Alto is being occupied by Amazon research Division according to Wikipedia: http://en.wikipedia.org/wiki/DEC_Systems_Research_Center I didn't make it to California, but I'm certain that we should go and ask over there. Thanks in advance --- El jue, 19/4/12, Dariusz Knoci?ski escribi?: > De: Dariusz Knoci?ski > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: m3devel at elegosoft.com, "Mika Nystrom" > Fecha: jueves, 19 de abril, 2012 12:38 > Dnia 2012-04-19, o godz. 10:29:18 > Mika Nystrom > napisa?(a): > > > > > But at the same time the Green Book (G. Nelson, ed., > Systems Programming > > with Modula-3, Prentice-Hall 1991) is probably the best > description of > > how to actually use object-oriented programming in > practice that's ever > > been published... > > > > It is a pity that Amazon does not send used books outside > the U.S., the seller > on eBay too. > > Best regards > Dariusz Knoci?ski. > From hendrik at topoi.pooq.com Fri Apr 20 04:32:39 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 19 Apr 2012 22:32:39 -0400 Subject: [M3devel] Modula-3 questions In-Reply-To: <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <4F902521.8000105@lcwb.coop> <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <20120420023238.GE5407@topoi.pooq.com> On Thu, Apr 19, 2012 at 05:30:36PM +0100, Daniel Alejandro Benavides D. wrote: > > Modula-3 modularity is more uniform from that. The nice thing about Module 3's modularity is that it's completely independent of procedures, object types, global variables, and all that. You can use the language the way you want to, and still be able to wrap up whatever kind of module makes sense for your application. -- hendrik From microcode at zoho.com Fri Apr 20 11:12:22 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Fri, 20 Apr 2012 09:12:22 +0000 Subject: [M3devel] Fw: Modula-3 questions Message-ID: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> I haven't found that book or any Modula-3 books online. I agree that things are often best left alone and often ruined by constant change and people who want to make things into other things they were never intended to be. I said something similar a few debates ago. I don't care what's popular as long as it still exists :-) ------Original Message------ From: Mika Nystrom To: microcode at zoho.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Fw: Modula-3 questions Sent: 19 Apr 2012 17:29 But at the same time the Green Book (G. Nelson, ed., Systems Programming with Modula-3, Prentice-Hall 1991) is probably the best description of how to actually use object-oriented programming in practice that's ever been published... I once wrote to whoever now owns Prentice-Hall and asked their copyright clearance person for permission to photocopy chapters of that book for a class I was teaching. No response, not even "absolutely not." But most of it (all of it??) is available online. I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that if the hordes discover it, they will ruin it. One LONGINT is enough headaches for me. I find the unchanging nature of the language to be a huge advantage in what I do. Mika -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. From rodney_bates at lcwb.coop Fri Apr 20 15:48:46 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 20 Apr 2012 08:48:46 -0500 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> References: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> Message-ID: <4F91693E.9000903@lcwb.coop> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: > I haven't found that book or any Modula-3 books online. > > I agree that things are often best left alone and often ruined by constant change and people who want to make things into other things they were never intended to be. I said something similar a few debates ago. I don't care what's popular as long as it still exists :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^ "As long as it still exists" is the critical connection to popularity here. It takes a certain minimum of interested people to keep it in existence. Despite being dramatically simpler than the alternatives, Modula-3 is still big enough that it needs several people to support it. We are really a bit low on this front. I can't seem to do the Modula-3 support I would like to do *and* use the language for my own projects too. And I'm retired. Frustrating. > > > > ------Original Message------ > From: Mika Nystrom > To: microcode at zoho.com > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Modula-3 questions > Sent: 19 Apr 2012 17:29 > > > But at the same time the Green Book (G. Nelson, ed., Systems Programming > with Modula-3, Prentice-Hall 1991) is probably the best description of > how to actually use object-oriented programming in practice that's ever > been published... > > I once wrote to whoever now owns Prentice-Hall and asked their copyright > clearance person for permission to photocopy chapters of that book > for a class I was teaching. No response, not even "absolutely not." > But most of it (all of it??) is available online. > > I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that > if the hordes discover it, they will ruin it. One LONGINT is enough > headaches for me. I find the unchanging nature of the language to be > a huge advantage in what I do. > > Mika > > -----Original Message----- > From: microcode at zoho.com > Date: Thu, 19 Apr 2012 16:49:57 > To: Daniel Alejandro Benavides D. > Reply-To: microcode at zoho.com > Subject: Re: [M3devel] Modula-3 questions > > A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? > > I see this as the biggest obstacle. > > > > From dabenavidesd at yahoo.es Fri Apr 20 16:13:06 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 15:13:06 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> Message-ID: <1334931186.57202.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Well in terms of popularity we could stand for Modula-3 in search engines and see how much we got and how much we got from other for instance say Java. It might be that there are a number of good results in Modula-3, so I don't know much effort to do countability of that. But this is just to state preeminence. Later the popularity the number of times it has been searched that word (not so recent results for google were not bad at all). Whether the community is alive and kicking I would ask another question to elucidate that clearly; if industry has a better and strong feeling for Java and C++, than for Modula-3, and computers are becoming because of the non-turning point of 40 years of crisis almost a dead end where as any new computer comes becomes substantially slower, then, I would say that would live in that Universe of industrial-strength systems are not alive by those languages, but of very "dead" languages (say Modula-3 'died' in 2000 but not talking about communities, just languages), so some good inspiration came from older days and make that industry still making some money. Concerning about community is just one or two people apart from the industrial-strength systems is certainly better since it reflects the likely it would be survived by someone, and I happen to believe that languages in **critical** times are lead by just one or maybe two people, the rest are just followers. We might create a Modula-3 facebook or social network account and quickly realize that there are dozens of people interested and get their hands dirty in this crisis no more but in a good "dead" language, if somebody says that then the language is still alive in those followers I believe so. Thanks in advance --- El vie, 20/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: viernes, 20 de abril, 2012 08:48 > > > On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > > I haven't found that book or any Modula-3 books > online. > > > > I agree that things are often best left alone and often > ruined by constant change and people who > want to make things into other things they were never > intended to be. I said something similar a few > debates ago. I don't care what's popular > as long as it still exists :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > "As long as it still exists" is the critical connection to > popularity here. It takes a certain minimum > of interested people to keep it in existence. Despite > being dramatically simpler than the alternatives, > Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this > front. > > I can't seem to do the Modula-3 support I would like to do > *and* use the language for my own projects > too. And I'm retired. Frustrating. > > > > > > > > > > > ------Original Message------ > > From: Mika Nystrom > > To: microcode at zoho.com > > Cc: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: Modula-3 questions > > Sent: 19 Apr 2012 17:29 > > > > > > But at the same time the Green Book (G. Nelson, ed., > Systems Programming > > with Modula-3, Prentice-Hall 1991) is probably the best > description of > > how to actually use object-oriented programming in > practice that's ever > > been published... > > > > I once wrote to whoever now owns Prentice-Hall and > asked their copyright > > clearance person for permission to photocopy chapters > of that book > > for a class I was teaching. No response, not even > "absolutely not." > > But most of it (all of it??) is available online. > > > > I'm somewhat ambivalent about marketing Modula-3 too > hard. I fear that > > if the hordes discover it, they will ruin it. One > LONGINT is enough > > headaches for me. I find the unchanging nature of > the language to be > > a huge advantage in what I do. > > > > Mika > > > > -----Original Message----- > > From: microcode at zoho.com > > Date: Thu, 19 Apr 2012 16:49:57 > > To: Daniel Alejandro Benavides D. > > Reply-To: microcode at zoho.com > > Subject: Re: [M3devel] Modula-3 questions > > > > A big inhibitor to Modula-3 is the lack of books and > tutorials. CM3 has a great system running on tons of > platforms. But where can people learn to code Modula-3? > > > > I see this as the biggest obstacle. > > > > > > > > > From microcode at zoho.com Fri Apr 20 17:12:43 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Fri, 20 Apr 2012 15:12:43 +0000 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> Message-ID: <20120420160023.925D3DE925@mx0.elegosoft.com> On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > On 04/20/2012 04:12 AM, microcode at zoho.com wrote: >> I haven't found that book or any Modula-3 books online. >> >> I agree that things are often best left alone and often ruined by >> constant change and people who want to make things into other things >> they were never intended to be. I said something similar a few debates >> ago. I don't care what's popular as long as it still exists :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^ > "As long as it still exists" is the critical connection to popularity > here. It takes a certain minimum of interested people to keep it in > existence. Despite being dramatically simpler than the alternatives, > Modula-3 is still big enough that it needs several people to support it. > We are really a bit low on this front. I don't know what's involved but I don't think I can be much help with coding, unfortunately. I have offered to help out with systems support in the past and the offer still stands. I can host a couple of development systems for Solaris 10 SPARC and Intel on an as-requested basis if developers need them to keep CM3 going. I believe those platforms are already supported so I don't think I'm helping much here either but just in case. > I can't seem to do the Modula-3 support I would like to do *and* use the > language for my own projects too. And I'm retired. Frustrating. Sounds like good problems to have. I will try to install CM3 on Solaris in the next few weeks. I had it on Linux but my install didn't seem like it was working since most of the examples got errors trying to build. I'm also busy with work and home stuff blah blah blah. I have a lot of things going on and I don't get to most of what I would like to either. I feel your pain ;-) From dabenavidesd at yahoo.es Fri Apr 20 18:06:38 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 17:06:38 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420023238.GE5407@topoi.pooq.com> Message-ID: <1334937998.62462.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: Interesting point but in original Modula [1], it was not that INTERFACE MODULEs were independent of, but monitors by them selves, and you could implement as you say, but later assumptions of that machines were not concurrent leave this concurrency out of the INTERFACEs. I believe that further developing that idea deserved more research than it's now, the concept of Objects as concurrent message sender receivers. Interestingly this the point of focus now on DDJ: http://www.drdobbs.com/parallel/232602463?cid=DDJ_nl_upd_2012-03-13_h&elq=be9ea13b9a534650b9e132e93de1931e The fact that the true roots of Modula's were in Mainframe machines if so, and before Object roots is appealing, o the idea is not original from them, though Some languages had featured Objects and messages before Small-talk way. So those machines were Module-oriented rather Object-oriented as some thought that is the leading architecture of new parallel systems [2] (p. 3). Thanks in advance [1] S. A. Williams, Programming models for parallel systems. J. Wiley, 1990. [2] R. Y. Kain, Computer architecture: software and hardware. Prentice Hall, 1989. --- El jue, 19/4/12, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 21:32 > On Thu, Apr 19, 2012 at 05:30:36PM > +0100, Daniel Alejandro Benavides D. wrote: > > > > Modula-3 modularity is more uniform from that. > > The nice thing about Module 3's modularity is that it's > completely > independent of procedures, object types, global variables, > and all that. > You can use the language the way you want to, and still be > able to wrap > up whatever kind of module makes sense for your > application. > > -- hendrik > From penn43 at gmx.com Fri Apr 20 21:24:24 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:24:24 +0200 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> References: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> <4F91693E.9000903@lcwb.coop> Message-ID: <20120420192424.27360@gmx.com> Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many language users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who need to maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh -------------- next part -------------- An HTML attachment was scrubbed... URL: From penn43 at gmx.com Fri Apr 20 21:30:25 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:30:25 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120420193025.27360@gmx.com> Sorry for double posting. I have just realized that my previous email was not visible (at least on Thunderbird), so I am posting it again here below. Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many Modula-3 users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who need to maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh From penn43 at gmx.com Fri Apr 20 21:37:17 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:37:17 +0200 Subject: [M3devel] Downsides of Modula-3 ? Message-ID: <20120420193717.27360@gmx.com> An object appraisal must take into account the problems too. So I am asking you, could you please mention any downsides of using Modula-3, in your experience? Of course, the non-existent language community has already been mentioned as a major downside. And the lack of documentation. What about other issues, such as compiler efficiency? Or interaction with foreign libraries? Thanks Marresh From penn43 at gmx.com Fri Apr 20 21:40:17 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:40:17 +0200 Subject: [M3devel] Downsides of Modula-3 ? Message-ID: <20120420194017.27360@gmx.com> > An object appraisal must take into account the problems too. So I am asking you, > could you please mention any downsides of using Modula-3, in your experience? Sorry, I meant to write "An objectIVE appraisal must..." From penn43 at gmx.com Fri Apr 20 21:45:08 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:45:08 +0200 Subject: [M3devel] Gtk2 binding Message-ID: <20120420194508.27350@gmx.com> > I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. Please, Dragi?a, could you share the binding with us? Thanks From dragisha at m3w.org Fri Apr 20 21:59:24 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 21:59:24 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <9553735C-579A-4564-BA89-66A42DEFE9E5@m3w.org> I don't see lack of documentation. On the contrary. Downside is - you are lone wolf. I am using a lot of foreign libraries and with C libs - no big problems. Last I used is/was libevent, and I made pretty complete OO binding around :). Efficiency of compiler, as well as ease of use is top notch. dd On Apr 20, 2012, at 9:37 PM, penn43 at gmx.com wrote: > An object appraisal must take into account the problems too. So I am asking you, could you please mention any downsides of using Modula-3, in your experience? > > Of course, the non-existent language community has already been mentioned as a major downside. > And the lack of documentation. > What about other issues, such as compiler efficiency? Or interaction with foreign libraries? > > Thanks > > Marresh From dragisha at m3w.org Fri Apr 20 22:00:33 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 22:00:33 +0200 Subject: [M3devel] Gtk2 binding In-Reply-To: <20120420194508.27350@gmx.com> References: <20120420194508.27350@gmx.com> Message-ID: <692013F4-7D06-497F-AD5C-0BA4EDCB3D62@m3w.org> If Rodney survives exposure :), I'll put a bit of effort into it and release it to public. dd On Apr 20, 2012, at 9:45 PM, penn43 at gmx.com wrote: > >> I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. > > Please, Dragi?a, could you share the binding with us? > Thanks > From mika at async.caltech.edu Fri Apr 20 22:14:37 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 13:14:37 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420193025.27360@gmx.com> References: <20120420193025.27360@gmx.com> Message-ID: <20120420201437.5C6BB1A205B@async.async.caltech.edu> penn43 at gmx.com writes: ... > >BTW How many Modula-3 users are there? This info can serve as a "reality check >", to establish whether the language is dying or not. >Also, are there newcomers to the language? Or the only programmers who use it >are those who need to maintain legacy code? Most crucially, are any NEW progra >ms written in the language? >These are crucial questions to assess the situation in a more objective way. W >hat are your views on these points? > >To start with, could you hint to what kind of projects (new/legacy code) you u >se Modula-3 for? Would you use Modula-3 if you had to start writing the same p >rograms from scratch? > >Thanks > > >Marresh > Whenever I have the choice I write new code in Modula-3 or some system built on top of it. The main projects I've done recently have been a Verilog test bench generator written in Scheme (run on top of M3); an analysis program for financial forecasting (using some "serious" matrix math, e.g., Singular Value Decomposition); a circuit timing verifier written in a combination of Modula-3 and Scheme, incorporating everything from efficient parsers (in-place parsing using recursive descent) to a simple calculus and interval arithmetic package (in Scheme); a high-frequency stock trading program (data-to-order latencies around 50 microseconds). Most of these projects would have been much more laborious with any other tool I know of, or would have involved some serious performance tradeoffs. Mika From schlepptop at henning-thielemann.de Fri Apr 20 22:14:19 2012 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 20 Apr 2012 22:14:19 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <4F91C39B.8020307@henning-thielemann.de> penn43 at gmx.com schrieb: > What about other issues, such as compiler efficiency? Or interaction with foreign libraries? INLINE across module boundaries would be nice. From dragisha at m3w.org Fri Apr 20 22:28:25 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 22:28:25 +0200 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420201437.5C6BB1A205B@async.async.caltech.edu> References: <20120420193025.27360@gmx.com> <20120420201437.5C6BB1A205B@async.async.caltech.edu> Message-ID: <448D516D-FA8F-4D7F-8078-8198BC2A1B21@m3w.org> Same here. Lone wolf aspect :). With enough luck, you write Modula-3 all the time. On Apr 20, 2012, at 10:14 PM, Mika Nystrom wrote: > Whenever I have the choice I write new code in Modula-3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Apr 20 22:29:46 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 13:29:46 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <20120420202946.0B35F1A205B@async.async.caltech.edu> Now that I have the rather unpleasant task of writing C code for a client, I have a few things I "like" about C and that I "miss" somewhat when I write Modula-3. I find that I sort of like the C preprocessor. But maybe it's just the sort of code I'm writing with it... (test programs, which need lots and lots of annotations and instrumentation, something easy to do with cpp). No alloca.... No varargs... No real "const" (Java "final"). Sometimes WITH can do it. No GO TO.............. can't believe I just wrote that but Modula-3 had as one of its design objectives to be a good target for code generation, and having goto would make that easier! (Look at the C-Mix partial evaluator for an application.) A C++ programmer would undoubtedly miss a lot of crazy C++ stuff that lets you do tricky stuff entirely without heap allocation. And operator overloading. Then there are some annoying implementation limitations: No EXTENDED floating point in the standard implementation. Bugs in the "standard" threading library (pthreads based). Have to use the longjmp hack version. Dubious "enhancements" relative to the Green Book: LONGINT, WIDECHAR (and a lot of issues with TEXT as a result). And efficiency problems in the CM3 code in *some cases* (compared with the older SRC M3). ---- My own evaluation of the above is that the things lacking relative to C are really pretty minor and the language is so much easier to use and better engineered that you almost never say to yourself "oh I wish I could write this procedure in C" (you might say it of one line of code). The implementation issues are things that could "easily" be fixed by someone who had the time.. Oh regarding efficiency problems: I still find that CM3 with optimization turned on produces code that runs faster and with a far smaller memory footprint than code doing the same thing in Java, most of the time. That's when you try to do as close to an apples-to-apples comparison as possible. If you take into account the fact that in Modula-3 you can allocate structured memory in "batches" (called "arrays"!) the difference is even bigger. Modula-3 also links far easier with C and Fortran than Java does. Mika penn43 at gmx.com writes: >An object appraisal must take into account the problems too. So I am asking yo >u, could you please mention any downsides of using Modula-3, in your experienc >e? > >Of course, the non-existent language community has already been mentioned as a > major downside. >And the lack of documentation. >What about other issues, such as compiler efficiency? Or interaction with fore >ign libraries? > >Thanks > >Marresh From penn43 at gmx.com Fri Apr 20 23:00:29 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 23:00:29 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120420210029.27340@gmx.com> > Same here. Lone wolf aspect Does the "lone wolf aspect" involve a lot of head-beating against the wall? Being a largely unsupported language, one may as well expect a lot of frustration. Honestly, how bad can it get? Any particularly problematic areas? Sorry if these nagging questions seem to you out of place. I am just trying to understand what I am getting into, if I decide to adopt Modula-3... Any real life experience greatly appreciated. From mika at async.caltech.edu Fri Apr 20 23:06:39 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 14:06:39 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420210029.27340@gmx.com> References: <20120420210029.27340@gmx.com> Message-ID: <20120420210639.D3F5A1A205B@async.async.caltech.edu> penn43 at gmx.com writes: >> Same here. Lone wolf aspect > >Does the "lone wolf aspect" involve a lot of head-beating against the wall? >Being a largely unsupported language, one may as well expect a lot of frustrat >ion. Honestly, how bad can it get? Any particularly problematic areas? People on this mailing list are very helpful, actually. Sometimes (see my previous email) the projects are a bit too big to tackle and those get left as restrictions. Serious user problems tend to happen with installation and if you care about some of the special things I mentioned in the last email. You generally don't need help with syntax (it's a simple language!) And if you want to learn "good style" I can highly recommend the Green Book's examples and some of the other libm3 code. If you need help with syntax it's generally with quake (the m3makefile language), not Modula-3 itself. In my experience this tends to happen when you want to do clever things with generics. Mika > >Sorry if these nagging questions seem to you out of place. I am just trying to > understand what I am getting into, if I decide to adopt Modula-3... Any real >life experience greatly appreciated. > From dabenavidesd at yahoo.es Fri Apr 20 23:30:31 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 22:30:31 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120420192424.27360@gmx.com> Message-ID: <1334957431.79315.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: The question it's nor complete because if there are a dozen of programmers doing something that quicks on dead languages we don't know (the larger the space the easier you can't expect an answer ), but the Universe of alive programmers in the language is easier to respond. My objective view of this is that, English speakers should like Modula-3 for processing language matters, because that's the point of a language speaker to understand and process linguistically any language written in it for post process and the only one I know that mathematically adheres to its constructs (and not even Scala nor Java are perfectly sound) is but with some sort of verification capabilities is Modula-3. I arrive at this point after hearing a comment that shows the difference technically of C++ and Modula-3 and said "Modula-3 is created for being able to prove its constructs, which C++ it by itself is not". This? technologies resort to very expressive systems, which is what Modula-3 is about You can look at SRI - PARC for Pegasys project under direction by Mark Moriconi. Thanks in advance --- El vie, 20/4/12, penn43 at gmx.com escribi?: De: penn43 at gmx.com Asunto: Re: [M3devel] Fw: Modula-3 questions Para: m3devel at elegosoft.com Fecha: viernes, 20 de abril, 2012 14:24 Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many language users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who?need to?maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views?on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Sat Apr 21 00:09:32 2012 From: mark at wickensonline.co.uk (Mark Wickens) Date: Fri, 20 Apr 2012 23:09:32 +0100 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <20120420160023.925D3DE925@mx0.elegosoft.com> References: <20120420160023.925D3DE925@mx0.elegosoft.com> Message-ID: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Hi guys, I've been following this conversation with interest. I'd like to offer my opinion, although I'm not sure I'm qualified that much to offer one. So please humour me ;) I've been a contract and permanent software engineer for over a decade now. Although it is said that you should learn a new language every year, I'm guessing the definition of the word 'learn' depends on the amount of time and intellectual power you can apply. In my case, and I'm not sure I can completely use this as an excuse, I have small children so the amount of time I've got to do anything is limited. I recognise there are limitations to any language, and Java has quite a few. Some say it has become the COBOL of the modern age. From my perspective, whilst there may be limitations, when I have a generic software problem to solve (and always in a hurry) it's very difficult to justify invest the time and effort to explore alternatives. Having said that, during Retrochallenge I've managed to code in both C, Pascal and VAX Macro (VAX/VMS languages). I did plan to spend a month coding Modula-3. This is still on the cards for a future competition. I find it very difficult to categorise programming languages in terms of interest. Clearly languages like C, C++, Java, .NET etc. with their commercial heritage are taught at University to provide students with a foot through the door to finding their first job. I ought to qualify that I'm thinking here of general purpose languages rather than domain-specific languages, such as PHP. Other languages such as Scala and Erlang are designed to try and progress the ease with which multi-process/thread applications can be developed. Other more domain-specific languages such as Ruby are attempting to solve web-centric problems... Interestingly I searched for 'programming languages hot' in google and one of the languages listed in the Infoworld article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 was COBOL, but this is primarily listed because of commercial interests. Searching job adverts for programming languages definitely won't get you the full picture. So then we have languages for academic or personal interest. So where do we think that Modula-3 fits into this picture? One thing is for sure, it's not considered a 'hot' language, so I don't think you'll find many Universities teaching it now we're into 2010+ (please, please correct me if I'm wrong). To a certain extent the participants on this list are skewed - I would imagine you could work on the Modula-3 compiler given enough architecture knowledge without necessarily having a huge amount of Modula-3 development experience. So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? Then there are people who have developed projects in Modula-3 and found it a nice/useful/productive language to develop with. Having invested time in the language it would make sense to use the language. So an alternative way of promoting the language would be to publish applications on the internet. I haven't searched for this, but I suspect that there aren't many recent articles. I have lots of other thoughts about the matter, but would welcome comments... Regards, Mark. Sent from my iPad On 20 Apr 2012, at 16:12, microcode at zoho.com wrote: > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > >> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: >>> I haven't found that book or any Modula-3 books online. >>> >>> I agree that things are often best left alone and often ruined by >>> constant change and people who want to make things into other things >>> they were never intended to be. I said something similar a few debates >>> ago. I don't care what's popular as long as it still exists :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> "As long as it still exists" is the critical connection to popularity >> here. It takes a certain minimum of interested people to keep it in >> existence. Despite being dramatically simpler than the alternatives, >> Modula-3 is still big enough that it needs several people to support it. >> We are really a bit low on this front. > > I don't know what's involved but I don't think I can be much help with > coding, unfortunately. I have offered to help out with systems support in > the past and the offer still stands. I can host a couple of development > systems for Solaris 10 SPARC and Intel on an as-requested basis if > developers need them to keep CM3 going. I believe those platforms are > already supported so I don't think I'm helping much here either but just in > case. > > >> I can't seem to do the Modula-3 support I would like to do *and* use the >> language for my own projects too. And I'm retired. Frustrating. > > Sounds like good problems to have. I will try to install CM3 on Solaris in > the next few weeks. I had it on Linux but my install didn't seem like it > was working since most of the examples got errors trying to build. I'm also > busy with work and home stuff blah blah blah. I have a lot of things going > on and I don't get to most of what I would like to either. I feel your > pain ;-) > > > From dabenavidesd at yahoo.es Sat Apr 21 01:41:49 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 00:41:49 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <1334965309.33491.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: nice idea, but it didn't work earlier, what should I work on something that anybody can do by their-selves, one of the most interesting things of learning a new language environment, is that to certain degree you are a baby in that world if you dare, that's how I feel about Modula-3, I cannot guarantee that because as Greg Nelson said, "Modula-3 definition will perpetually incomplete" and computationally he was right but depending on the tool used for doing that affirmation. Thanks in advance PS Now, imagine if they dare to define a model of software based on any language, but just if it were Modula-3 or any "real" language, the rest is just the same thing over and over again, projects that never deserve any mention. --- El vie, 20/4/12, Mark Wickens escribi?: > De: Mark Wickens > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" > Fecha: viernes, 20 de abril, 2012 17:09 > Hi guys, > > I've been following this conversation with interest. I'd > like to offer my opinion, although I'm not sure I'm > qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for > over a decade now. Although it is said that you should learn > a new language every year, I'm guessing the definition of > the word 'learn' depends on the amount of time and > intellectual power you can apply. In my case, and I'm not > sure I can completely use this as an excuse, I have small > children so the amount of time I've got to do anything is > limited. > > I recognise there are limitations to any language, and Java > has quite a few. Some say it has become the COBOL of the > modern age. From my perspective, whilst there may be > limitations, when I have a generic software problem to solve > (and always in a hurry) it's very difficult to justify > invest the time and effort to explore alternatives. Having > said that, during Retrochallenge I've managed to code in > both C, Pascal and VAX Macro (VAX/VMS languages). I did plan > to spend a month coding Modula-3. This is still on the cards > for a future competition. > > I find it very difficult to categorise programming languages > in terms of interest. Clearly languages like C, C++, Java, > .NET etc. with their commercial heritage are taught at > University to provide students with a foot through the door > to finding their first job. I ought to qualify that I'm > thinking here of general purpose languages rather than > domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try > and progress the ease with which multi-process/thread > applications can be developed. Other more domain-specific > languages such as Ruby are attempting to solve web-centric > problems... > > Interestingly I searched for 'programming languages hot' in > google and one of the languages listed in the Infoworld > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > was COBOL, but this is primarily listed because of > commercial interests. Searching job adverts for programming > languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. > So where do we think that Modula-3 fits into this picture? > One thing is for sure, it's not considered a 'hot' language, > so I don't think you'll find many Universities teaching it > now we're into 2010+ (please, please correct me if I'm > wrong). > > To a certain extent the participants on this list are skewed > - I would imagine you could work on the Modula-3 compiler > given enough architecture knowledge without necessarily > having a huge amount of Modula-3 development experience. So > could development on the compiler be sold as a way of > gaining concrete skills in compiler development (IIRC it's > all developed in C)? > > Then there are people who have developed projects in > Modula-3 and found it a nice/useful/productive language to > develop with. Having invested time in the language it would > make sense to use the language. > > So an alternative way of promoting the language would be to > publish applications on the internet. > I haven't searched for this, but I suspect that there aren't > many recent articles. > > I have lots of other thoughts about the matter, but would > welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com > wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > >>> I haven't found that book or any Modula-3 books > online. > >>> > >>> I agree that things are often best left alone > and often ruined by > >>> constant change and people who want to make > things into other things > >>> they were never intended to be. I said > something similar a few debates > >>> ago. I don't care what's popular as long as it > still exists :-) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical > connection to popularity > >> here. It takes a certain minimum of > interested people to keep it in > >> existence. Despite being dramatically simpler > than the alternatives, > >> Modula-3 is still big enough that it needs several > people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be > much help with > > coding, unfortunately. I have offered to help out with > systems support in > > the past and the offer still stands. I can host a > couple of development > > systems for Solaris 10 SPARC and Intel on an > as-requested basis if > > developers need them to keep CM3 going. I believe those > platforms are > > already supported so I don't think I'm helping much > here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would > like to do *and* use the > >> language for my own projects too. And I'm > retired. Frustrating. > > > > Sounds like good problems to have. I will try to > install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install > didn't seem like it > > was working since most of the examples got errors > trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a > lot of things going > > on and I don't get to most of what I would like to > either. I feel your > > pain ;-) > > > > > > > From dabenavidesd at yahoo.es Sat Apr 21 03:30:42 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 02:30:42 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <1334965309.33491.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <1334971842.99402.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: the last phrase taken from here: http://books.google.com.co/books?id=M3F-lhug50cC&lpg=PP1&pg=PA137#v=onepage&q&f=false and before that [1] (I clarify further real-world languages doesn't include neither Oberon or its relative cousin Java, nor Smalltalk, so this is easier to proof literally) [1] I. A. and E. S. Society, COMPASS ?94: proceedings of the Ninth Annual Conference on Computer Assurance?: June 27-July 1, 1994, National Institute of Standards and Technology, Gaithersburg, MD?: safety, reliability, fault tolerance, concurrency and real time security. Institute of Electrical and Electronics Engineers, 1994. --- El vie, 20/4/12, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" , "Mark Wickens" > Fecha: viernes, 20 de abril, 2012 18:41 > Hi all: > nice idea, but it didn't work earlier, what should I work on > something that anybody can do by their-selves, one of > the most interesting things of learning a new language > environment, is that to certain degree you are a baby in > that world if you dare, that's how I feel about Modula-3, I > cannot guarantee that because as Greg Nelson said, "Modula-3 > definition will perpetually incomplete" and computationally > he was right but depending on the tool used for doing that > affirmation. > Thanks in advance > > PS Now, imagine if they dare to define a model of software > based on any language, but just if it were Modula-3 or any > "real" language, the rest is just the same thing over and > over again, projects that never deserve any mention. > > --- El vie, 20/4/12, Mark Wickens > escribi?: > > > De: Mark Wickens > > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 > questions > > Para: "m3devel at elegosoft.com" > > > Fecha: viernes, 20 de abril, 2012 17:09 > > Hi guys, > > > > I've been following this conversation with interest. > I'd > > like to offer my opinion, although I'm not sure I'm > > qualified that much to offer one. So please humour me > ;) > > > > I've been a contract and permanent software engineer > for > > over a decade now. Although it is said that you should > learn > > a new language every year, I'm guessing the definition > of > > the word 'learn' depends on the amount of time and > > intellectual power you can apply. In my case, and I'm > not > > sure I can completely use this as an excuse, I have > small > > children so the amount of time I've got to do anything > is > > limited. > > > > I recognise there are limitations to any language, and > Java > > has quite a few. Some say it has become the COBOL of > the > > modern age. From my perspective, whilst there may be > > limitations, when I have a generic software problem to > solve > > (and always in a hurry) it's very difficult to justify > > invest the time and effort to explore alternatives. > Having > > said that, during Retrochallenge I've managed to code > in > > both C, Pascal and VAX Macro (VAX/VMS languages). I did > plan > > to spend a month coding Modula-3. This is still on the > cards > > for a future competition. > > > > I find it very difficult to categorise programming > languages > > in terms of interest. Clearly languages like C, C++, > Java, > > .NET etc. with their commercial heritage are taught at > > University to provide students with a foot through the > door > > to finding their first job. I ought to qualify that > I'm > > thinking here of general purpose languages rather than > > domain-specific languages, such as PHP. > > > > Other languages such as Scala and Erlang are designed > to try > > and progress the ease with which multi-process/thread > > applications can be developed. Other more > domain-specific > > languages such as Ruby are attempting to solve > web-centric > > problems... > > > > Interestingly I searched for 'programming languages > hot' in > > google and one of the languages listed in the > Infoworld > > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > > was COBOL, but this is primarily listed because of > > commercial interests. Searching job adverts for > programming > > languages definitely won't get you the full picture. > > > > So then we have languages for academic or personal > interest. > > So where do we think that Modula-3 fits into this > picture? > > One thing is for sure, it's not considered a 'hot' > language, > > so I don't think you'll find many Universities teaching > it > > now we're into 2010+ (please, please correct me if I'm > > wrong). > > > > To a certain extent the participants on this list are > skewed > > - I would imagine you could work on the Modula-3 > compiler > > given enough architecture knowledge without > necessarily > > having a huge amount of Modula-3 development > experience. So > > could development on the compiler be sold as a way of > > gaining concrete skills in compiler development (IIRC > it's > > all developed in C)? > > > > Then there are people who have developed projects in > > Modula-3 and found it a nice/useful/productive language > to > > develop with. Having invested time in the language it > would > > make sense to use the language. > > > > So an alternative way of promoting the language would > be to > > publish applications on the internet. > > I haven't searched for this, but I suspect that there > aren't > > many recent articles. > > > > I have lots of other thoughts about the matter, but > would > > welcome comments... > > > > Regards, Mark. > > > > Sent from my iPad > > > > On 20 Apr 2012, at 16:12, microcode at zoho.com > > wrote: > > > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > > wrote > > > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > > wrote: > > >>> I haven't found that book or any Modula-3 > books > > online. > > >>> > > >>> I agree that things are often best left > alone > > and often ruined by > > >>> constant change and people who want to > make > > things into other things > > >>> they were never intended to be. I said > > something similar a few debates > > >>> ago. I don't care what's popular as long > as it > > still exists :-) > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > >> "As long as it still exists" is the critical > > connection to popularity > > >> here. It takes a certain minimum of > > interested people to keep it in > > >> existence. Despite being dramatically > simpler > > than the alternatives, > > >> Modula-3 is still big enough that it needs > several > > people to support it. > > >> We are really a bit low on this front. > > > > > > I don't know what's involved but I don't think I > can be > > much help with > > > coding, unfortunately. I have offered to help out > with > > systems support in > > > the past and the offer still stands. I can host a > > couple of development > > > systems for Solaris 10 SPARC and Intel on an > > as-requested basis if > > > developers need them to keep CM3 going. I believe > those > > platforms are > > > already supported so I don't think I'm helping > much > > here either but just in > > > case. > > > > > > > > >> I can't seem to do the Modula-3 support I > would > > like to do *and* use the > > >> language for my own projects too. And > I'm > > retired. Frustrating. > > > > > > Sounds like good problems to have. I will try to > > install CM3 on Solaris in > > > the next few weeks. I had it on Linux but my > install > > didn't seem like it > > > was working since most of the examples got errors > > trying to build. I'm also > > > busy with work and home stuff blah blah blah. I > have a > > lot of things going > > > on and I don't get to most of what I would like > to > > either. I feel your > > > pain ;-) > > > > > > > > > > > > From jay.krell at cornell.edu Sat Apr 21 05:33:01 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Apr 2012 03:33:01 +0000 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> References: <20120420160023.925D3DE925@mx0.elegosoft.com>, <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: > So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? This merits correction: The compile is largely written in Modula-3. It is broken up into a "builder", front end, other parts, and backends. The NT/x86 backend is written in Modula-3 and outputs .obj files directly. The "builder", front end, middle stuff, cross-module checking stuff (something related to "linking", depending on your point of view), NT/x86 backend are all linked into one executable -- cm3. The other backend is gcc. When using it cm3 outputs an intermediate form, that the gcc thing reads back in. The rest is written in Modula-3. - Jay > From: mark at wickensonline.co.uk > Date: Fri, 20 Apr 2012 23:09:32 +0100 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > > Hi guys, > > I've been following this conversation with interest. I'd like to offer my opinion, although I'm not sure I'm qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for over a decade now. Although it is said that you should learn a new language every year, I'm guessing the definition of the word 'learn' depends on the amount of time and intellectual power you can apply. In my case, and I'm not sure I can completely use this as an excuse, I have small children so the amount of time I've got to do anything is limited. > > I recognise there are limitations to any language, and Java has quite a few. Some say it has become the COBOL of the modern age. From my perspective, whilst there may be limitations, when I have a generic software problem to solve (and always in a hurry) it's very difficult to justify invest the time and effort to explore alternatives. Having said that, during Retrochallenge I've managed to code in both C, Pascal and VAX Macro (VAX/VMS languages). I did plan to spend a month coding Modula-3. This is still on the cards for a future competition. > > I find it very difficult to categorise programming languages in terms of interest. Clearly languages like C, C++, Java, .NET etc. with their commercial heritage are taught at University to provide students with a foot through the door to finding their first job. I ought to qualify that I'm thinking here of general purpose languages rather than domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try and progress the ease with which multi-process/thread applications can be developed. Other more domain-specific languages such as Ruby are attempting to solve web-centric problems... > > Interestingly I searched for 'programming languages hot' in google and one of the languages listed in the Infoworld article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 was COBOL, but this is primarily listed because of commercial interests. Searching job adverts for programming languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. So where do we think that Modula-3 fits into this picture? One thing is for sure, it's not considered a 'hot' language, so I don't think you'll find many Universities teaching it now we're into 2010+ (please, please correct me if I'm wrong). > > To a certain extent the participants on this list are skewed - I would imagine you could work on the Modula-3 compiler given enough architecture knowledge without necessarily having a huge amount of Modula-3 development experience. So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? > > Then there are people who have developed projects in Modula-3 and found it a nice/useful/productive language to develop with. Having invested time in the language it would make sense to use the language. > > So an alternative way of promoting the language would be to publish applications on the internet. > I haven't searched for this, but I suspect that there aren't many recent articles. > > I have lots of other thoughts about the matter, but would welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: > >>> I haven't found that book or any Modula-3 books online. > >>> > >>> I agree that things are often best left alone and often ruined by > >>> constant change and people who want to make things into other things > >>> they were never intended to be. I said something similar a few debates > >>> ago. I don't care what's popular as long as it still exists :-) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical connection to popularity > >> here. It takes a certain minimum of interested people to keep it in > >> existence. Despite being dramatically simpler than the alternatives, > >> Modula-3 is still big enough that it needs several people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be much help with > > coding, unfortunately. I have offered to help out with systems support in > > the past and the offer still stands. I can host a couple of development > > systems for Solaris 10 SPARC and Intel on an as-requested basis if > > developers need them to keep CM3 going. I believe those platforms are > > already supported so I don't think I'm helping much here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would like to do *and* use the > >> language for my own projects too. And I'm retired. Frustrating. > > > > Sounds like good problems to have. I will try to install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install didn't seem like it > > was working since most of the examples got errors trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a lot of things going > > on and I don't get to most of what I would like to either. I feel your > > pain ;-) > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Sat Apr 21 08:43:22 2012 From: mark at wickensonline.co.uk (Mark Wickens) Date: Sat, 21 Apr 2012 07:43:22 +0100 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: References: <20120420160023.925D3DE925@mx0.elegosoft.com>, <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <4F92570A.6090302@wickensonline.co.uk> On 21/04/12 04:33, Jay K wrote: > > So could development on the compiler be sold as a way of gaining > concrete skills in compiler development (IIRC it's all developed in C)? > > This merits correction: > The compile is largely written in Modula-3. > It is broken up into a "builder", front end, other parts, and backends. > The NT/x86 backend is written in Modula-3 and outputs .obj files > directly. > The "builder", front end, middle stuff, cross-module checking stuff > (something related to "linking", depending on your point of > view), NT/x86 backend are all linked into one executable -- cm3. > The other backend is gcc. When using it cm3 outputs an intermediate > form, that the gcc thing reads back in. > The rest is written in Modula-3. > Hi Jay, Thanks for the clarification. Having sent the email I did start to wonder whether I was correct in my statement... it's been a while since I looked at Modula-3! On an operational note I got a 'Certificate Not Trusted' error when attempting to access the roadmap https://projects.elego.de/cm3/roadmap. Regards, Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Apr 21 15:40:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 14:40:04 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <1335015604.28434.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi Mark: if I'm not correct there please forgive but it is a possible answer to that picture you are trying to diagnose (specially maybe you can correct since you have known the VAX-RISC style machines of VAX9000 series if so), but I dare to believe that they put on those machines besides of VMS and Ultrix some sort of a Modula-3 OS because that was the only possible side for installing and running such a beasts smoothly. DEC abandoned the high needs application market because of marketing failures and misunderstandings (such as Parallelizing Fortran Compiler), but they have sold their right to market its super computer architecture designs to MasPar, and other computers are still supported in emulation companies and run in "Windows". Thanks in advance --- El vie, 20/4/12, Mark Wickens escribi?: > De: Mark Wickens > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" > Fecha: viernes, 20 de abril, 2012 17:09 > Hi guys, > > I've been following this conversation with interest. I'd > like to offer my opinion, although I'm not sure I'm > qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for > over a decade now. Although it is said that you should learn > a new language every year, I'm guessing the definition of > the word 'learn' depends on the amount of time and > intellectual power you can apply. In my case, and I'm not > sure I can completely use this as an excuse, I have small > children so the amount of time I've got to do anything is > limited. > > I recognise there are limitations to any language, and Java > has quite a few. Some say it has become the COBOL of the > modern age. From my perspective, whilst there may be > limitations, when I have a generic software problem to solve > (and always in a hurry) it's very difficult to justify > invest the time and effort to explore alternatives. Having > said that, during Retrochallenge I've managed to code in > both C, Pascal and VAX Macro (VAX/VMS languages). I did plan > to spend a month coding Modula-3. This is still on the cards > for a future competition. > > I find it very difficult to categorise programming languages > in terms of interest. Clearly languages like C, C++, Java, > .NET etc. with their commercial heritage are taught at > University to provide students with a foot through the door > to finding their first job. I ought to qualify that I'm > thinking here of general purpose languages rather than > domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try > and progress the ease with which multi-process/thread > applications can be developed. Other more domain-specific > languages such as Ruby are attempting to solve web-centric > problems... > > Interestingly I searched for 'programming languages hot' in > google and one of the languages listed in the Infoworld > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > was COBOL, but this is primarily listed because of > commercial interests. Searching job adverts for programming > languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. > So where do we think that Modula-3 fits into this picture? > One thing is for sure, it's not considered a 'hot' language, > so I don't think you'll find many Universities teaching it > now we're into 2010+ (please, please correct me if I'm > wrong). > > To a certain extent the participants on this list are skewed > - I would imagine you could work on the Modula-3 compiler > given enough architecture knowledge without necessarily > having a huge amount of Modula-3 development experience. So > could development on the compiler be sold as a way of > gaining concrete skills in compiler development (IIRC it's > all developed in C)? > > Then there are people who have developed projects in > Modula-3 and found it a nice/useful/productive language to > develop with. Having invested time in the language it would > make sense to use the language. > > So an alternative way of promoting the language would be to > publish applications on the internet. > I haven't searched for this, but I suspect that there aren't > many recent articles. > > I have lots of other thoughts about the matter, but would > welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com > wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > >>> I haven't found that book or any Modula-3 books > online. > >>> > >>> I agree that things are often best left alone > and often ruined by > >>> constant change and people who want to make > things into other things > >>> they were never intended to be. I said > something similar a few debates > >>> ago. I don't care what's popular as long as it > still exists :-) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical > connection to popularity > >> here. It takes a certain minimum of > interested people to keep it in > >> existence. Despite being dramatically simpler > than the alternatives, > >> Modula-3 is still big enough that it needs several > people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be > much help with > > coding, unfortunately. I have offered to help out with > systems support in > > the past and the offer still stands. I can host a > couple of development > > systems for Solaris 10 SPARC and Intel on an > as-requested basis if > > developers need them to keep CM3 going. I believe those > platforms are > > already supported so I don't think I'm helping much > here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would > like to do *and* use the > >> language for my own projects too. And I'm > retired. Frustrating. > > > > Sounds like good problems to have. I will try to > install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install > didn't seem like it > > was working since most of the examples got errors > trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a > lot of things going > > on and I don't get to most of what I would like to > either. I feel your > > pain ;-) > > > > > > > From dabenavidesd at yahoo.es Sat Apr 21 18:26:48 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 17:26:48 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420202946.0B35F1A205B@async.async.caltech.edu> Message-ID: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. Thanks in advance --- El vie, 20/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: penn43 at gmx.com > CC: m3devel at elegosoft.com > Fecha: viernes, 20 de abril, 2012 15:29 > > Now that I have the rather unpleasant task of writing C code > for a client, > I have a few things I "like" about C and that I "miss" > somewhat when > I write Modula-3. > > I find that I sort of like the C preprocessor. But > maybe it's just the > sort of code I'm writing with it... (test programs, which > need lots and > lots of annotations and instrumentation, something easy to > do with cpp). > > No alloca.... > > No varargs... > > No real "const" (Java "final"). Sometimes WITH can do > it. > > No GO TO.............. can't believe I just wrote that but > Modula-3 had > as one of its design objectives to be a good target for code > generation, > and having goto would make that easier! (Look at the > C-Mix partial > evaluator for an application.) > > A C++ programmer would undoubtedly miss a lot of crazy C++ > stuff > that lets you do tricky stuff entirely without heap > allocation. > And operator overloading. > > Then there are some annoying implementation limitations: > > No EXTENDED floating point in the standard implementation. > > Bugs in the "standard" threading library (pthreads > based). Have > to use the longjmp hack version. > > Dubious "enhancements" relative to the Green Book: LONGINT, > WIDECHAR > (and a lot of issues with TEXT as a result). And > efficiency problems > in the CM3 code in *some cases* (compared with the older SRC > M3). > > ---- > > My own evaluation of the above is that the things lacking > relative to C > are really pretty minor and the language is so much easier > to use > and better engineered that you almost never say to yourself > "oh I wish > I could write this procedure in C" (you might say it of one > line of code). > > The implementation issues are things that could "easily" be > fixed by > someone who had the time.. > > Oh regarding efficiency problems: I still find that CM3 with > optimization > turned on produces code that runs faster and with a far > smaller memory > footprint than code doing the same thing in Java, most of > the time. > That's when you try to do as close to an apples-to-apples > comparison > as possible. If you take into account the fact that in > Modula-3 you can > allocate structured memory in "batches" (called "arrays"!) > the difference > is even bigger. Modula-3 also links far easier with C > and Fortran than > Java does. > > Mika > > > > penn43 at gmx.com > writes: > >An object appraisal must take into account the problems > too. So I am asking yo > >u, could you please mention any downsides of using > Modula-3, in your experienc > >e? > > > >Of course, the non-existent language community has > already been mentioned as a > > major downside. > >And the lack of documentation. > >What about other issues, such as compiler efficiency? Or > interaction with fore > >ign libraries? > > > >Thanks > > > >Marresh > From dknoto at next.com.pl Sat Apr 21 20:26:03 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Sat, 21 Apr 2012 20:26:03 +0200 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: References: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com> <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: <20120421202603.6ed1896b@wenus.next.com.pl> Dnia 2012-02-03, o godz. 16:13:55 Jay K napisa?(a): I finally found some time on the second approach to compile CM3 from source. I have got latest source from 2012/04/13. > Darious, how about cm3 -commands -keep? These options have not tried. > This sort of error indicates either the wrong cm3cg is being run or it is > being passed the wrong file, like mixing up .ic and .io files or somesuch. > Try adding -v to the cm3cg commands. You'll have to cd to the target > directory as well (AMD64_LINUX). > > I added option "-v" to the command "./do-cm3-core.sh -v buildship" and got the following result: >>> ... === package /home/dknoto/Oprogramowanie/Modula-3/Source/m3-libs/m3core === +++ cm3 -build -DROOT='/home/dknoto/Oprogramowanie/Modula-3/Source' $RARGS && cm3 -ship $RARGS -DROOT='/home/dknoto/Oprogramowanie/Modula-3/Source' +++ EVAL ("/usr/local/cm3/bin/cm3.cfg") --- building in AMD64_LINUX --- cd AMD64_LINUX ignoring ../src/m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES inhale libm3core.m3x checking RTBuiltin.mx reading "../src/runtime/common/RTBuiltin.mx": 0 seconds checking RTHooks.i3 new source -> compiling RTHooks.i3 m3front ../src/runtime/common/RTHooks.i3 -w1 /home/dknoto/Oprogramowanie/Modula-3/Source/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks RTHooks .ic -o RTHooks.is m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. m3_backend => 1 m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic rm RTHooks.is rm RTHooks.ic rm RTHooks.is checking RTHooks.m3 checking RuntimeError.i3 checking RT0.i3 <<< In directory m3-libs/m3core/AMD64_LINUX I have not file libm3core.so.5, but I have files *.o and file libm3core.m3x. I added the full building log to the attachment. Best regards Dariusz Knoci?ski. -------------- next part -------------- A non-text attachment was scrubbed... Name: buildship-2012-04-21_19-57.log.xz Type: application/x-xz Size: 23528 bytes Desc: not available URL: From dragisha at m3w.org Sat Apr 21 23:28:15 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 21 Apr 2012 23:28:15 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: What would be LONGADDRESS? Pointer to a location inside LONGRAM? :) On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? > Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. > Thanks in advance > > --- El vie, 20/4/12, Mika Nystrom escribi?: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: penn43 at gmx.com >> CC: m3devel at elegosoft.com >> Fecha: viernes, 20 de abril, 2012 15:29 >> >> Now that I have the rather unpleasant task of writing C code >> for a client, >> I have a few things I "like" about C and that I "miss" >> somewhat when >> I write Modula-3. >> >> I find that I sort of like the C preprocessor. But >> maybe it's just the >> sort of code I'm writing with it... (test programs, which >> need lots and >> lots of annotations and instrumentation, something easy to >> do with cpp). >> >> No alloca.... >> >> No varargs... >> >> No real "const" (Java "final"). Sometimes WITH can do >> it. >> >> No GO TO.............. can't believe I just wrote that but >> Modula-3 had >> as one of its design objectives to be a good target for code >> generation, >> and having goto would make that easier! (Look at the >> C-Mix partial >> evaluator for an application.) >> >> A C++ programmer would undoubtedly miss a lot of crazy C++ >> stuff >> that lets you do tricky stuff entirely without heap >> allocation. >> And operator overloading. >> >> Then there are some annoying implementation limitations: >> >> No EXTENDED floating point in the standard implementation. >> >> Bugs in the "standard" threading library (pthreads >> based). Have >> to use the longjmp hack version. >> >> Dubious "enhancements" relative to the Green Book: LONGINT, >> WIDECHAR >> (and a lot of issues with TEXT as a result). And >> efficiency problems >> in the CM3 code in *some cases* (compared with the older SRC >> M3). >> >> ---- >> >> My own evaluation of the above is that the things lacking >> relative to C >> are really pretty minor and the language is so much easier >> to use >> and better engineered that you almost never say to yourself >> "oh I wish >> I could write this procedure in C" (you might say it of one >> line of code). >> >> The implementation issues are things that could "easily" be >> fixed by >> someone who had the time.. >> >> Oh regarding efficiency problems: I still find that CM3 with >> optimization >> turned on produces code that runs faster and with a far >> smaller memory >> footprint than code doing the same thing in Java, most of >> the time. >> That's when you try to do as close to an apples-to-apples >> comparison >> as possible. If you take into account the fact that in >> Modula-3 you can >> allocate structured memory in "batches" (called "arrays"!) >> the difference >> is even bigger. Modula-3 also links far easier with C >> and Fortran than >> Java does. >> >> Mika >> >> >> >> penn43 at gmx.com >> writes: >>> An object appraisal must take into account the problems >> too. So I am asking yo >>> u, could you please mention any downsides of using >> Modula-3, in your experienc >>> e? >>> >>> Of course, the non-existent language community has >> already been mentioned as a >>> major downside. >>> And the lack of documentation. >>> What about other issues, such as compiler efficiency? Or >> interaction with fore >>> ign libraries? >>> >>> Thanks >>> >>> Marresh >> From jay.krell at cornell.edu Sun Apr 22 01:22:37 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Apr 2012 23:22:37 +0000 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com>, Message-ID: I don't understand what LONGADDRESS is either. > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. 1) please elaborate 2) We don't use longjmp as much any more, but get/set/make/swapcontext on platforms that support them.And where we do use longjmp, we have a more portable use than before -- we no longer hack on the jmpbuf.There is a "trick" where you use sigsetstack or some such to get the stack pointer into the jmpbuf.Look at the code and read the paper referenced. It is possible it didn't work on all platforms. But anyway, see #1.We'd really prefer to just use pthreads.Hm. I'd like to look again at what pthreads features we use -- I suspect pthreads/Win32 can beabstracted more thinly and the Modula-3 code less-forked/more-shared. But later.. - Jay > From: dragisha at m3w.org > Date: Sat, 21 Apr 2012 23:28:15 +0200 > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Downsides of Modula-3 ? > > What would be LONGADDRESS? Pointer to a location inside LONGRAM? :) > > On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? > > Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. > > Thanks in advance > > > > --- El vie, 20/4/12, Mika Nystrom escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: penn43 at gmx.com > >> CC: m3devel at elegosoft.com > >> Fecha: viernes, 20 de abril, 2012 15:29 > >> > >> Now that I have the rather unpleasant task of writing C code > >> for a client, > >> I have a few things I "like" about C and that I "miss" > >> somewhat when > >> I write Modula-3. > >> > >> I find that I sort of like the C preprocessor. But > >> maybe it's just the > >> sort of code I'm writing with it... (test programs, which > >> need lots and > >> lots of annotations and instrumentation, something easy to > >> do with cpp). > >> > >> No alloca.... > >> > >> No varargs... > >> > >> No real "const" (Java "final"). Sometimes WITH can do > >> it. > >> > >> No GO TO.............. can't believe I just wrote that but > >> Modula-3 had > >> as one of its design objectives to be a good target for code > >> generation, > >> and having goto would make that easier! (Look at the > >> C-Mix partial > >> evaluator for an application.) > >> > >> A C++ programmer would undoubtedly miss a lot of crazy C++ > >> stuff > >> that lets you do tricky stuff entirely without heap > >> allocation. > >> And operator overloading. > >> > >> Then there are some annoying implementation limitations: > >> > >> No EXTENDED floating point in the standard implementation. > >> > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. > >> > >> Dubious "enhancements" relative to the Green Book: LONGINT, > >> WIDECHAR > >> (and a lot of issues with TEXT as a result). And > >> efficiency problems > >> in the CM3 code in *some cases* (compared with the older SRC > >> M3). > >> > >> ---- > >> > >> My own evaluation of the above is that the things lacking > >> relative to C > >> are really pretty minor and the language is so much easier > >> to use > >> and better engineered that you almost never say to yourself > >> "oh I wish > >> I could write this procedure in C" (you might say it of one > >> line of code). > >> > >> The implementation issues are things that could "easily" be > >> fixed by > >> someone who had the time.. > >> > >> Oh regarding efficiency problems: I still find that CM3 with > >> optimization > >> turned on produces code that runs faster and with a far > >> smaller memory > >> footprint than code doing the same thing in Java, most of > >> the time. > >> That's when you try to do as close to an apples-to-apples > >> comparison > >> as possible. If you take into account the fact that in > >> Modula-3 you can > >> allocate structured memory in "batches" (called "arrays"!) > >> the difference > >> is even bigger. Modula-3 also links far easier with C > >> and Fortran than > >> Java does. > >> > >> Mika > >> > >> > >> > >> penn43 at gmx.com > >> writes: > >>> An object appraisal must take into account the problems > >> too. So I am asking yo > >>> u, could you please mention any downsides of using > >> Modula-3, in your experienc > >>> e? > >>> > >>> Of course, the non-existent language community has > >> already been mentioned as a > >>> major downside. > >>> And the lack of documentation. > >>> What about other issues, such as compiler efficiency? Or > >> interaction with fore > >>> ign libraries? > >>> > >>> Thanks > >>> > >>> Marresh > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 22 01:36:10 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 21 Apr 2012 16:36:10 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com>, Message-ID: <20120421233610.B48281A205B@async.async.caltech.edu> Jay K writes: >1) please elaborate >2) We don't use longjmp as much any more=2C but get/set= >/make/swapcontext on platforms that support them.And where we do use longjm= >p=2C we have a more portable use than before -- we no longer hack on the jm= >pbuf.There is a "trick" where you use sigsetstack or some such to get the s= >tack pointer into the jmpbuf.Look at the code and read the paper referenced= >. It is possible it didn't work on all platforms. But anyway=2C see #1.We'= >d really prefer to just use pthreads.Hm. I'd like to look again at what pth= >reads features we use -- I suspect pthreads/Win32 can beabstracted more thi= >nly and the Modula-3 code less-forked/more-shared. But later.. - Jay > Fro= Sorry for the bad quote. My mailer still lives in the 7-bit world. In any case I was just mentioning as a problem with the current Modula-3 implementation that the pthreads bindings are buggy. I would not (and do not) use them for serious work. And user threads are, as we all know, not ideal... Anybody who wants to investigate the matter can start by running the thread testing program in m3core/tests/thread ... Main.m3 is fairly well documented. Mika From dabenavidesd at yahoo.es Sun Apr 22 18:41:28 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 17:41:28 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120421233610.B48281A205B@async.async.caltech.edu> Message-ID: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I'm more suspicious about the back needs over this programs, since Win32 programs have worked OK, have they? So I agree with you it's a matter of target implementation (not UNSAFE world), but that's in m3gcc backend, isn't it? Similarly your code could be fixed to uniprocessor semantics, so if this tests are OK either pthreads or embedded M3 threads this is a clear symptom of that UP semantics issue. In any case don't expect too many threads to do that correctly, since any exception in them can't be managed by Modula-3 RT (by language definition) but at most in m3gcc semantics I believe so. DECthreads had a nice mechanism to wrap it to Modula-3 style semantics so it could be easier to offer that in a internal CM3 API. Thanks in advance --- El s?b, 21/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Jay K" > CC: m3devel at elegosoft.com > Fecha: s?bado, 21 de abril, 2012 18:36 > Jay K writes: > >1) please elaborate > > >2) We don't use longjmp as much any more=2C but > get/set= > >/make/swapcontext on platforms that support them.And > where we do use longjm= > >p=2C we have a more portable use than before -- we no > longer hack on the jm= > >pbuf.There is a "trick" where you use sigsetstack or > some such to get the s= > >tack pointer into the jmpbuf.Look at the code and read > the paper referenced= > >. It is possible it didn't work on all platforms. > But anyway=2C see #1.We'= > >d really prefer to just use pthreads.Hm. I'd like to > look again at what pth= > >reads features we use -- I suspect pthreads/Win32 can > beabstracted more thi= > >nly and the Modula-3 code less-forked/more-shared. But > later.. - Jay > Fro= > > Sorry for the bad quote. My mailer still lives in the > 7-bit world. > > In any case I was just mentioning as a problem with the > current Modula-3 > implementation that the pthreads bindings are buggy. I > would not (and > do not) use them for serious work. And user threads > are, as we all know, > not ideal... > > Anybody who wants to investigate the matter can start by > running the thread > testing program in m3core/tests/thread ... Main.m3 is > fairly well documented. > > Mika > From dabenavidesd at yahoo.es Sun Apr 22 19:18:46 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 18:18:46 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: Message-ID: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space. Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit. Then the question what it would be like AMD64. Thanks in advance --- El s?b, 21/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com > Fecha: s?bado, 21 de abril, 2012 16:28 > What would be LONGADDRESS? Pointer to > a location inside LONGRAM? :) > > On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > If we accept to exist LONGINT and ADDRESS is a Word.T > why we don't have LONGADDRESS? That's you don't care if > that's in UNSAFE TYPE, do you? > > Assembly in lining was handled about perfect in > Modula-2 for VMS I wonder why DEC didn't provide Modula-3 > support with that as well. > > Thanks in advance > > > > --- El vie, 20/4/12, Mika Nystrom > escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: penn43 at gmx.com > >> CC: m3devel at elegosoft.com > >> Fecha: viernes, 20 de abril, 2012 15:29 > >> > >> Now that I have the rather unpleasant task of > writing C code > >> for a client, > >> I have a few things I "like" about C and that I > "miss" > >> somewhat when > >> I write Modula-3. > >> > >> I find that I sort of like the C > preprocessor. But > >> maybe it's just the > >> sort of code I'm writing with it... (test programs, > which > >> need lots and > >> lots of annotations and instrumentation, something > easy to > >> do with cpp). > >> > >> No alloca.... > >> > >> No varargs... > >> > >> No real "const" (Java "final"). Sometimes > WITH can do > >> it. > >> > >> No GO TO.............. can't believe I just wrote > that but > >> Modula-3 had > >> as one of its design objectives to be a good target > for code > >> generation, > >> and having goto would make that easier! (Look > at the > >> C-Mix partial > >> evaluator for an application.) > >> > >> A C++ programmer would undoubtedly miss a lot of > crazy C++ > >> stuff > >> that lets you do tricky stuff entirely without > heap > >> allocation. > >> And operator overloading. > >> > >> Then there are some annoying implementation > limitations: > >> > >> No EXTENDED floating point in the standard > implementation. > >> > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. > >> > >> Dubious "enhancements" relative to the Green Book: > LONGINT, > >> WIDECHAR > >> (and a lot of issues with TEXT as a result). > And > >> efficiency problems > >> in the CM3 code in *some cases* (compared with the > older SRC > >> M3). > >> > >> ---- > >> > >> My own evaluation of the above is that the things > lacking > >> relative to C > >> are really pretty minor and the language is so much > easier > >> to use > >> and better engineered that you almost never say to > yourself > >> "oh I wish > >> I could write this procedure in C" (you might say > it of one > >> line of code). > >> > >> The implementation issues are things that could > "easily" be > >> fixed by > >> someone who had the time.. > >> > >> Oh regarding efficiency problems: I still find that > CM3 with > >> optimization > >> turned on produces code that runs faster and with a > far > >> smaller memory > >> footprint than code doing the same thing in Java, > most of > >> the time. > >> That's when you try to do as close to an > apples-to-apples > >> comparison > >> as possible. If you take into account the > fact that in > >> Modula-3 you can > >> allocate structured memory in "batches" (called > "arrays"!) > >> the difference > >> is even bigger. Modula-3 also links far > easier with C > >> and Fortran than > >> Java does. > >> > >> Mika > >> > >> > >> > >> penn43 at gmx.com > >> writes: > >>> An object appraisal must take into account the > problems > >> too. So I am asking yo > >>> u, could you please mention any downsides of > using > >> Modula-3, in your experienc > >>> e? > >>> > >>> Of course, the non-existent language community > has > >> already been mentioned as a > >>> major downside. > >>> And the lack of documentation. > >>> What about other issues, such as compiler > efficiency? Or > >> interaction with fore > >>> ign libraries? > >>> > >>> Thanks > >>> > >>> Marresh > >> > > From mika at async.caltech.edu Sun Apr 22 19:30:34 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Apr 2012 10:30:34 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <20120422173034.8ED311A205B@async.async.caltech.edu> I'm almost certain the problem is somewhere in the pthreads implementation of M3 threads, which consists of a couple of files of C and M3 within m3core. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >I'm more suspicious about the back needs over this programs, since Win32 pr= >ograms have worked OK, have they? So I agree with you it's a matter of targ= >et implementation (not UNSAFE world), but that's in m3gcc backend, isn't it= >? >Similarly your code could be fixed to uniprocessor semantics, so if this te= >sts are OK either pthreads or embedded M3 threads this is a clear symptom o= >f that UP semantics issue. >In any case don't expect too many threads to do that correctly, since any e= >xception in them can't be managed by Modula-3 RT (by language definition) b= >ut at most in m3gcc semantics I believe so. DECthreads had a nice mechanism= > to wrap it to Modula-3 style semantics so it could be easier to offer that= > in a internal CM3 API. >Thanks in advance > > >--- El s=E1b, 21/4/12, Mika Nystrom escribi=F3: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Jay K" >> CC: m3devel at elegosoft.com >> Fecha: s=E1bado, 21 de abril, 2012 18:36 >> Jay K writes: >> >1) please elaborate=20 >>=20 >> >2) We don't use longjmp as much any more=3D2C but >> get/set=3D >> >/make/swapcontext on platforms that support them.And >> where we do use longjm=3D >> >p=3D2C we have a more portable use than before -- we no >> longer hack on the jm=3D >> >pbuf.There is a "trick" where you use sigsetstack or >> some such to get the s=3D >> >tack pointer into the jmpbuf.Look at the code and read >> the paper referenced=3D >> >. It is possible it didn't work on all platforms.=20 >> But anyway=3D2C see #1.We'=3D >> >d really prefer to just use pthreads.Hm. I'd like to >> look again at what pth=3D >> >reads features we use -- I suspect pthreads/Win32 can >> beabstracted more thi=3D >> >nly and the Modula-3 code less-forked/more-shared. But >> later.. - Jay > Fro=3D >>=20 >> Sorry for the bad quote. My mailer still lives in the >> 7-bit world. >>=20 >> In any case I was just mentioning as a problem with the >> current Modula-3 >> implementation that the pthreads bindings are buggy. I >> would not (and >> do not) use them for serious work. And user threads >> are, as we all know, >> not ideal... >>=20 >> Anybody who wants to investigate the matter can start by >> running the thread >> testing program in m3core/tests/thread ... Main.m3 is >> fairly well documented. >>=20 >> Mika >> From mika at async.caltech.edu Sun Apr 22 19:43:28 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Apr 2012 10:43:28 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <20120422174328.68DB81A205B@async.async.caltech.edu> But the thing is, if the produced code were thread unsafe, it likely wouldn't work with user threads either... I admit what you say is possible but it ought to be ruled out by the semantics of pthreads. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >Please this makes think that the current systems are a lottery, because the= >y don't mark thread-safe code (or they are all safe assumed as thread-unsaf= >e): >http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe > >Even if they compiler is not threaded by itself it can cause a back-end to = >be thread-unsafe, so that's why I say that it could be in that back-end. > >But then the code must be marked by each module and I think assuming all ar= >e thread-unsafe is correct to say. >Thanks in advance > >--- El dom, 22/4/12, Mika Nystrom escribi=F3: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Daniel Alejandro Benavides D." >> CC: m3devel at elegosoft.com >> Fecha: domingo, 22 de abril, 2012 12:30 >>=20 >> I'm almost certain the problem is somewhere in the pthreads >> implementation >> of M3 threads, which consists of a couple of files of C and >> M3 within >> m3core. >>=20 >> Mika >>=20 >> "Daniel Alejandro Benavides D." writes: >> >Hi all: >> >I'm more suspicious about the back needs over this >> programs, since Win32 pr=3D >> >ograms have worked OK, have they? So I agree with you >> it's a matter of targ=3D >> >et implementation (not UNSAFE world), but that's in >> m3gcc backend, isn't it=3D >> >? >> >Similarly your code could be fixed to uniprocessor >> semantics, so if this te=3D >> >sts are OK either pthreads or embedded M3 threads this >> is a clear symptom o=3D >> >f that UP semantics issue. >> >In any case don't expect too many threads to do that >> correctly, since any e=3D >> >xception in them can't be managed by Modula-3 RT (by >> language definition) b=3D >> >ut at most in m3gcc semantics I believe so. DECthreads >> had a nice mechanism=3D >> > to wrap it to Modula-3 style semantics so it could be >> easier to offer that=3D >> > in a internal CM3 API. >> >Thanks in advance >> > >> > >> >--- El s=3DE1b, 21/4/12, Mika Nystrom >> escribi=3DF3: >> > >> >> De: Mika Nystrom >> >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> >> Para: "Jay K" >> >> CC: m3devel at elegosoft.com >> >> Fecha: s=3DE1bado, 21 de abril, 2012 18:36 >> >> Jay K writes: >> >> >1) please elaborate=3D20 >> >>=3D20 >> >> >2) We don't use longjmp as much any more=3D3D2C >> but >> >> get/set=3D3D >> >> >/make/swapcontext on platforms that support >> them.And >> >> where we do use longjm=3D3D >> >> >p=3D3D2C we have a more portable use than before >> -- we no >> >> longer hack on the jm=3D3D >> >> >pbuf.There is a "trick" where you use >> sigsetstack or >> >> some such to get the s=3D3D >> >> >tack pointer into the jmpbuf.Look at the code >> and read >> >> the paper referenced=3D3D >> >> >. It is possible it didn't work on all >> platforms.=3D20 >> >> But anyway=3D3D2C see #1.We'=3D3D >> >> >d really prefer to just use pthreads.Hm. I'd >> like to >> >> look again at what pth=3D3D >> >> >reads features we use -- I suspect >> pthreads/Win32 can >> >> beabstracted more thi=3D3D >> >> >nly and the Modula-3 code >> less-forked/more-shared. But >> >> later.. - Jay > Fro=3D3D >> >>=3D20 >> >> Sorry for the bad quote. My mailer still >> lives in the >> >> 7-bit world. >> >>=3D20 >> >> In any case I was just mentioning as a problem with >> the >> >> current Modula-3 >> >> implementation that the pthreads bindings are >> buggy. I >> >> would not (and >> >> do not) use them for serious work. And user >> threads >> >> are, as we all know, >> >> not ideal... >> >>=3D20 >> >> Anybody who wants to investigate the matter can >> start by >> >> running the thread >> >> testing program in m3core/tests/thread ...=20 >> Main.m3 is >> >> fairly well documented. >> >>=3D20 >> >> Mika >> >>=20 >> From dabenavidesd at yahoo.es Sun Apr 22 19:40:31 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 18:40:31 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120422173034.8ED311A205B@async.async.caltech.edu> Message-ID: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Please this makes think that the current systems are a lottery, because they don't mark thread-safe code (or they are all safe assumed as thread-unsafe): http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe Even if they compiler is not threaded by itself it can cause a back-end to be thread-unsafe, so that's why I say that it could be in that back-end. But then the code must be marked by each module and I think assuming all are thread-unsafe is correct to say. Thanks in advance --- El dom, 22/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 12:30 > > I'm almost certain the problem is somewhere in the pthreads > implementation > of M3 threads, which consists of a couple of files of C and > M3 within > m3core. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I'm more suspicious about the back needs over this > programs, since Win32 pr= > >ograms have worked OK, have they? So I agree with you > it's a matter of targ= > >et implementation (not UNSAFE world), but that's in > m3gcc backend, isn't it= > >? > >Similarly your code could be fixed to uniprocessor > semantics, so if this te= > >sts are OK either pthreads or embedded M3 threads this > is a clear symptom o= > >f that UP semantics issue. > >In any case don't expect too many threads to do that > correctly, since any e= > >xception in them can't be managed by Modula-3 RT (by > language definition) b= > >ut at most in m3gcc semantics I believe so. DECthreads > had a nice mechanism= > > to wrap it to Modula-3 style semantics so it could be > easier to offer that= > > in a internal CM3 API. > >Thanks in advance > > > > > >--- El s=E1b, 21/4/12, Mika Nystrom > escribi=F3: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Jay K" > >> CC: m3devel at elegosoft.com > >> Fecha: s=E1bado, 21 de abril, 2012 18:36 > >> Jay K writes: > >> >1) please elaborate=20 > >>=20 > >> >2) We don't use longjmp as much any more=3D2C > but > >> get/set=3D > >> >/make/swapcontext on platforms that support > them.And > >> where we do use longjm=3D > >> >p=3D2C we have a more portable use than before > -- we no > >> longer hack on the jm=3D > >> >pbuf.There is a "trick" where you use > sigsetstack or > >> some such to get the s=3D > >> >tack pointer into the jmpbuf.Look at the code > and read > >> the paper referenced=3D > >> >. It is possible it didn't work on all > platforms.=20 > >> But anyway=3D2C see #1.We'=3D > >> >d really prefer to just use pthreads.Hm. I'd > like to > >> look again at what pth=3D > >> >reads features we use -- I suspect > pthreads/Win32 can > >> beabstracted more thi=3D > >> >nly and the Modula-3 code > less-forked/more-shared. But > >> later.. - Jay > Fro=3D > >>=20 > >> Sorry for the bad quote. My mailer still > lives in the > >> 7-bit world. > >>=20 > >> In any case I was just mentioning as a problem with > the > >> current Modula-3 > >> implementation that the pthreads bindings are > buggy. I > >> would not (and > >> do not) use them for serious work. And user > threads > >> are, as we all know, > >> not ideal... > >>=20 > >> Anybody who wants to investigate the matter can > start by > >> running the thread > >> testing program in m3core/tests/thread ... > Main.m3 is > >> fairly well documented. > >>=20 > >> Mika > >> > From dabenavidesd at yahoo.es Sun Apr 22 20:01:21 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 19:01:21 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120422174328.68DB81A205B@async.async.caltech.edu> Message-ID: <1335117681.25789.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I agree too, but then that is assuming that you code is inherently thread-safe, which we don't care either or worse in Modula-e libraries BTW, we could have THREADSAFE or SAFE keyword of that and so ... Now, what Antony and someone once said, that "embedded" green threads are not that semantically correct assuming some things over them (for instance UP semantics), then we should make some primitives for handling the new implementation of threads just to be sure. Thanks in advance --- El dom, 22/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 12:43 > > But the thing is, if the produced code were thread unsafe, > it likely > wouldn't work with user threads either... > > I admit what you say is possible but it ought to be ruled > out by the > semantics of pthreads. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >Please this makes think that the current systems are a > lottery, because the= > >y don't mark thread-safe code (or they are all safe > assumed as thread-unsaf= > >e): > >http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe > > > >Even if they compiler is not threaded by itself it can > cause a back-end to = > >be thread-unsafe, so that's why I say that it could be > in that back-end. > > > >But then the code must be marked by each module and I > think assuming all ar= > >e thread-unsafe is correct to say. > >Thanks in advance > > > >--- El dom, 22/4/12, Mika Nystrom > escribi=F3: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Daniel Alejandro Benavides D." > >> CC: m3devel at elegosoft.com > >> Fecha: domingo, 22 de abril, 2012 12:30 > >>=20 > >> I'm almost certain the problem is somewhere in the > pthreads > >> implementation > >> of M3 threads, which consists of a couple of files > of C and > >> M3 within > >> m3core. > >>=20 > >> Mika > >>=20 > >> "Daniel Alejandro Benavides D." writes: > >> >Hi all: > >> >I'm more suspicious about the back needs over > this > >> programs, since Win32 pr=3D > >> >ograms have worked OK, have they? So I agree > with you > >> it's a matter of targ=3D > >> >et implementation (not UNSAFE world), but > that's in > >> m3gcc backend, isn't it=3D > >> >? > >> >Similarly your code could be fixed to > uniprocessor > >> semantics, so if this te=3D > >> >sts are OK either pthreads or embedded M3 > threads this > >> is a clear symptom o=3D > >> >f that UP semantics issue. > >> >In any case don't expect too many threads to do > that > >> correctly, since any e=3D > >> >xception in them can't be managed by Modula-3 > RT (by > >> language definition) b=3D > >> >ut at most in m3gcc semantics I believe so. > DECthreads > >> had a nice mechanism=3D > >> > to wrap it to Modula-3 style semantics so it > could be > >> easier to offer that=3D > >> > in a internal CM3 API. > >> >Thanks in advance > >> > > >> > > >> >--- El s=3DE1b, 21/4/12, Mika Nystrom > >> escribi=3DF3: > >> > > >> >> De: Mika Nystrom > >> >> Asunto: Re: [M3devel] Downsides of > Modula-3 ? > >> >> Para: "Jay K" > >> >> CC: m3devel at elegosoft.com > >> >> Fecha: s=3DE1bado, 21 de abril, 2012 > 18:36 > >> >> Jay K writes: > >> >> >1) please elaborate=3D20 > >> >>=3D20 > >> >> >2) We don't use longjmp as much any > more=3D3D2C > >> but > >> >> get/set=3D3D > >> >> >/make/swapcontext on platforms that > support > >> them.And > >> >> where we do use longjm=3D3D > >> >> >p=3D3D2C we have a more portable use > than before > >> -- we no > >> >> longer hack on the jm=3D3D > >> >> >pbuf.There is a "trick" where you use > >> sigsetstack or > >> >> some such to get the s=3D3D > >> >> >tack pointer into the jmpbuf.Look at > the code > >> and read > >> >> the paper referenced=3D3D > >> >> >. It is possible it didn't work on > all > >> platforms.=3D20 > >> >> But anyway=3D3D2C see #1.We'=3D3D > >> >> >d really prefer to just use > pthreads.Hm. I'd > >> like to > >> >> look again at what pth=3D3D > >> >> >reads features we use -- I suspect > >> pthreads/Win32 can > >> >> beabstracted more thi=3D3D > >> >> >nly and the Modula-3 code > >> less-forked/more-shared. But > >> >> later.. - Jay > Fro=3D3D > >> >>=3D20 > >> >> Sorry for the bad quote. My mailer > still > >> lives in the > >> >> 7-bit world. > >> >>=3D20 > >> >> In any case I was just mentioning as a > problem with > >> the > >> >> current Modula-3 > >> >> implementation that the pthreads bindings > are > >> buggy. I > >> >> would not (and > >> >> do not) use them for serious work. > And user > >> threads > >> >> are, as we all know, > >> >> not ideal... > >> >>=3D20 > >> >> Anybody who wants to investigate the > matter can > >> start by > >> >> running the thread > >> >> testing program in m3core/tests/thread > ...=20 > >> Main.m3 is > >> >> fairly well documented. > >> >>=3D20 > >> >> Mika > >> >>=20 > >> > From rodney_bates at lcwb.coop Sun Apr 22 20:43:07 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Apr 2012 13:43:07 -0500 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <4F94513B.3060802@lcwb.coop> On 04/22/2012 11:41 AM, Daniel Alejandro Benavides D. wrote: > Hi all: > I'm more suspicious about the back needs over this programs, since Win32 programs have worked OK, have they? So I agree with you it's a matter of target implementation (not UNSAFE world), but that's in m3gcc backend, isn't it? > Similarly your code could be fixed to uniprocessor semantics, so if this tests are OK either pthreads or embedded M3 threads this is a clear symptom of that UP semantics issue. > In any case don't expect too many threads to do that correctly, since any exception in them can't be managed by Modula-3 RT (by language definition) I'm not sure what you mean by this, but in my reading, the language definition fully defines the interaction between threads and exceptions. Exceptions can propagate only within a thread. All the rules about where they propagate are in terms of either a statically enclosing block or a dynamic parent, that is, the caller of the current procedure. In both cases, it's strictly within the thread where the exception was raised. If an exception ever got to the top of the call chain of its thread, it would have to be the result of an override of the apply method of the closure passed to Thread.Fork. But that method has an empty RAISES clause, so if that should happen, it would be a runtime error, still within the thread. but at most in m3gcc semantics I believe so. DECthreads had a nice mechanism to wrap it to Modula-3 style semantics so it could be easier to offer that in a internal CM3 API. > Thanks in advance > > > --- El s?b, 21/4/12, Mika Nystrom escribi?: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Jay K" >> CC: m3devel at elegosoft.com >> Fecha: s?bado, 21 de abril, 2012 18:36 >> Jay K writes: >>> 1) please elaborate >> >>> 2) We don't use longjmp as much any more=2C but >> get/set= >>> /make/swapcontext on platforms that support them.And >> where we do use longjm= >>> p=2C we have a more portable use than before -- we no >> longer hack on the jm= >>> pbuf.There is a "trick" where you use sigsetstack or >> some such to get the s= >>> tack pointer into the jmpbuf.Look at the code and read >> the paper referenced= >>> . It is possible it didn't work on all platforms. >> But anyway=2C see #1.We'= >>> d really prefer to just use pthreads.Hm. I'd like to >> look again at what pth= >>> reads features we use -- I suspect pthreads/Win32 can >> beabstracted more thi= >>> nly and the Modula-3 code less-forked/more-shared. But >> later.. - Jay> Fro= >> >> Sorry for the bad quote. My mailer still lives in the >> 7-bit world. >> >> In any case I was just mentioning as a problem with the >> current Modula-3 >> implementation that the pthreads bindings are buggy. I >> would not (and >> do not) use them for serious work. And user threads >> are, as we all know, >> not ideal... >> >> Anybody who wants to investigate the matter can start by >> running the thread >> testing program in m3core/tests/thread ... Main.m3 is >> fairly well documented. >> >> Mika >> > From dragisha at m3w.org Sun Apr 22 20:50:42 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 22 Apr 2012 20:50:42 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: In other words, let's invent another non-portability :). Pass, please :) On Apr 22, 2012, at 7:18 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space. > Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit. > Then the question what it would be like AMD64. > Thanks in advance > > --- El s?b, 21/4/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Daniel Alejandro Benavides D." >> CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com >> Fecha: s?bado, 21 de abril, 2012 16:28 >> What would be LONGADDRESS? Pointer to >> a location inside LONGRAM? :) >> >> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. >> wrote: >> >>> Hi all: >>> If we accept to exist LONGINT and ADDRESS is a Word.T >> why we don't have LONGADDRESS? That's you don't care if >> that's in UNSAFE TYPE, do you? >>> Assembly in lining was handled about perfect in >> Modula-2 for VMS I wonder why DEC didn't provide Modula-3 >> support with that as well. >>> Thanks in advance >>> >>> --- El vie, 20/4/12, Mika Nystrom >> escribi?: >>> >>>> De: Mika Nystrom >>>> Asunto: Re: [M3devel] Downsides of Modula-3 ? >>>> Para: penn43 at gmx.com >>>> CC: m3devel at elegosoft.com >>>> Fecha: viernes, 20 de abril, 2012 15:29 >>>> >>>> Now that I have the rather unpleasant task of >> writing C code >>>> for a client, >>>> I have a few things I "like" about C and that I >> "miss" >>>> somewhat when >>>> I write Modula-3. >>>> >>>> I find that I sort of like the C >> preprocessor. But >>>> maybe it's just the >>>> sort of code I'm writing with it... (test programs, >> which >>>> need lots and >>>> lots of annotations and instrumentation, something >> easy to >>>> do with cpp). >>>> >>>> No alloca.... >>>> >>>> No varargs... >>>> >>>> No real "const" (Java "final"). Sometimes >> WITH can do >>>> it. >>>> >>>> No GO TO.............. can't believe I just wrote >> that but >>>> Modula-3 had >>>> as one of its design objectives to be a good target >> for code >>>> generation, >>>> and having goto would make that easier! (Look >> at the >>>> C-Mix partial >>>> evaluator for an application.) >>>> >>>> A C++ programmer would undoubtedly miss a lot of >> crazy C++ >>>> stuff >>>> that lets you do tricky stuff entirely without >> heap >>>> allocation. >>>> And operator overloading. >>>> >>>> Then there are some annoying implementation >> limitations: >>>> >>>> No EXTENDED floating point in the standard >> implementation. >>>> >>>> Bugs in the "standard" threading library (pthreads >>>> based). Have >>>> to use the longjmp hack version. >>>> >>>> Dubious "enhancements" relative to the Green Book: >> LONGINT, >>>> WIDECHAR >>>> (and a lot of issues with TEXT as a result). >> And >>>> efficiency problems >>>> in the CM3 code in *some cases* (compared with the >> older SRC >>>> M3). >>>> >>>> ---- >>>> >>>> My own evaluation of the above is that the things >> lacking >>>> relative to C >>>> are really pretty minor and the language is so much >> easier >>>> to use >>>> and better engineered that you almost never say to >> yourself >>>> "oh I wish >>>> I could write this procedure in C" (you might say >> it of one >>>> line of code). >>>> >>>> The implementation issues are things that could >> "easily" be >>>> fixed by >>>> someone who had the time.. >>>> >>>> Oh regarding efficiency problems: I still find that >> CM3 with >>>> optimization >>>> turned on produces code that runs faster and with a >> far >>>> smaller memory >>>> footprint than code doing the same thing in Java, >> most of >>>> the time. >>>> That's when you try to do as close to an >> apples-to-apples >>>> comparison >>>> as possible. If you take into account the >> fact that in >>>> Modula-3 you can >>>> allocate structured memory in "batches" (called >> "arrays"!) >>>> the difference >>>> is even bigger. Modula-3 also links far >> easier with C >>>> and Fortran than >>>> Java does. >>>> >>>> Mika >>>> >>>> >>>> >>>> penn43 at gmx.com >>>> writes: >>>>> An object appraisal must take into account the >> problems >>>> too. So I am asking yo >>>>> u, could you please mention any downsides of >> using >>>> Modula-3, in your experienc >>>>> e? >>>>> >>>>> Of course, the non-existent language community >> has >>>> already been mentioned as a >>>>> major downside. >>>>> And the lack of documentation. >>>>> What about other issues, such as compiler >> efficiency? Or >>>> interaction with fore >>>>> ign libraries? >>>>> >>>>> Thanks >>>>> >>>>> Marresh >>>> >> >> From penn43 at gmx.com Mon Apr 23 16:30:06 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Mon, 23 Apr 2012 16:30:06 +0200 Subject: [M3devel] Support for UTF-8 and email protocols Message-ID: <20120423143006.27340@gmx.com> Hi, sorry if I asked this question before, but it went unanswered and I really need to know. Are there available libraries that support: 1) UTF-8 text 2) email protocols (SMTP and POP3) -- I need client-side support ONLY. (These two functionalities are distinct, of course.) Thanks Marresh From dabenavidesd at yahoo.es Mon Apr 23 23:46:53 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Apr 2012 22:46:53 +0100 (BST) Subject: [M3devel] Support for UTF-8 and email protocols In-Reply-To: <20120423143006.27340@gmx.com> Message-ID: <1335217613.54933.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: Support of basics is there but there isn't too much in examples, etc. WIDECHAR type is the basic building block for your UTF support, but you need to be wise, somehow, it is still untested by most of us. Support for the protocol on that eagerly needs work, I don't any known free coded server system that is portable for truth, so I'd guess that unless somebody needed it, nobody has yet one client for Modula-3 or such. Instead there could be an approach but it's too much top-down using GenVoca coming from Avoca OS written in Modula-3 for writing network protocols. I hope it helps. Thanks in advance --- El lun, 23/4/12, penn43 at gmx.com escribi?: > De: penn43 at gmx.com > Asunto: [M3devel] Support for UTF-8 and email protocols > Para: m3devel at elegosoft.com > Fecha: lunes, 23 de abril, 2012 09:30 > Hi, > > sorry if I asked this question before, but it went > unanswered and I really need to know. > > Are there available libraries that support: > > 1) UTF-8 text > > 2) email protocols (SMTP and POP3) -- I need client-side > support ONLY. > > (These two functionalities are distinct, of course.) > > Thanks > > Marresh > > From dabenavidesd at yahoo.es Tue Apr 24 16:42:39 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 24 Apr 2012 15:42:39 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance --- El dom, 22/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 13:50 > In other words, let's invent another > non-portability :). > > Pass, please :) > > On Apr 22, 2012, at 7:18 PM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > I think it would be in I386 (I remember were 16 bits) > and absolute address location of a Word.T were handled as > such in I386 process at least that's in my MSJ Vol. 7 No.4, > because it has Application Address Space and at top System > Address Space. > > Similarly in ARMv7the virtual address space is 32-bit, > but physically extended to be 40-bit. > > Then the question what it would be like AMD64. > > Thanks in advance > > > > --- El s?b, 21/4/12, Dragi?a Duri? > escribi?: > > > >> De: Dragi?a Duri? > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Daniel Alejandro Benavides D." > >> CC: penn43 at gmx.com, > "Mika Nystrom" , > m3devel at elegosoft.com > >> Fecha: s?bado, 21 de abril, 2012 16:28 > >> What would be LONGADDRESS? Pointer to > >> a location inside LONGRAM? :) > >> > >> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro > Benavides D. > >> wrote: > >> > >>> Hi all: > >>> If we accept to exist LONGINT and ADDRESS is a > Word.T > >> why we don't have LONGADDRESS? That's you don't > care if > >> that's in UNSAFE TYPE, do you? > >>> Assembly in lining was handled about perfect > in > >> Modula-2 for VMS I wonder why DEC didn't provide > Modula-3 > >> support with that as well. > >>> Thanks in advance > >>> > >>> --- El vie, 20/4/12, Mika Nystrom > >> escribi?: > >>> > >>>> De: Mika Nystrom > >>>> Asunto: Re: [M3devel] Downsides of Modula-3 > ? > >>>> Para: penn43 at gmx.com > >>>> CC: m3devel at elegosoft.com > >>>> Fecha: viernes, 20 de abril, 2012 15:29 > >>>> > >>>> Now that I have the rather unpleasant task > of > >> writing C code > >>>> for a client, > >>>> I have a few things I "like" about C and > that I > >> "miss" > >>>> somewhat when > >>>> I write Modula-3. > >>>> > >>>> I find that I sort of like the C > >> preprocessor. But > >>>> maybe it's just the > >>>> sort of code I'm writing with it... (test > programs, > >> which > >>>> need lots and > >>>> lots of annotations and instrumentation, > something > >> easy to > >>>> do with cpp). > >>>> > >>>> No alloca.... > >>>> > >>>> No varargs... > >>>> > >>>> No real "const" (Java "final"). > Sometimes > >> WITH can do > >>>> it. > >>>> > >>>> No GO TO.............. can't believe I just > wrote > >> that but > >>>> Modula-3 had > >>>> as one of its design objectives to be a > good target > >> for code > >>>> generation, > >>>> and having goto would make that > easier! (Look > >> at the > >>>> C-Mix partial > >>>> evaluator for an application.) > >>>> > >>>> A C++ programmer would undoubtedly miss a > lot of > >> crazy C++ > >>>> stuff > >>>> that lets you do tricky stuff entirely > without > >> heap > >>>> allocation. > >>>> And operator overloading. > >>>> > >>>> Then there are some annoying > implementation > >> limitations: > >>>> > >>>> No EXTENDED floating point in the standard > >> implementation. > >>>> > >>>> Bugs in the "standard" threading library > (pthreads > >>>> based). Have > >>>> to use the longjmp hack version. > >>>> > >>>> Dubious "enhancements" relative to the > Green Book: > >> LONGINT, > >>>> WIDECHAR > >>>> (and a lot of issues with TEXT as a > result). > >> And > >>>> efficiency problems > >>>> in the CM3 code in *some cases* (compared > with the > >> older SRC > >>>> M3). > >>>> > >>>> ---- > >>>> > >>>> My own evaluation of the above is that the > things > >> lacking > >>>> relative to C > >>>> are really pretty minor and the language is > so much > >> easier > >>>> to use > >>>> and better engineered that you almost never > say to > >> yourself > >>>> "oh I wish > >>>> I could write this procedure in C" (you > might say > >> it of one > >>>> line of code). > >>>> > >>>> The implementation issues are things that > could > >> "easily" be > >>>> fixed by > >>>> someone who had the time.. > >>>> > >>>> Oh regarding efficiency problems: I still > find that > >> CM3 with > >>>> optimization > >>>> turned on produces code that runs faster > and with a > >> far > >>>> smaller memory > >>>> footprint than code doing the same thing in > Java, > >> most of > >>>> the time. > >>>> That's when you try to do as close to an > >> apples-to-apples > >>>> comparison > >>>> as possible. If you take into account > the > >> fact that in > >>>> Modula-3 you can > >>>> allocate structured memory in "batches" > (called > >> "arrays"!) > >>>> the difference > >>>> is even bigger. Modula-3 also links > far > >> easier with C > >>>> and Fortran than > >>>> Java does. > >>>> > >>>> Mika > >>>> > >>>> > >>>> > >>>> penn43 at gmx.com > >>>> writes: > >>>>> An object appraisal must take into > account the > >> problems > >>>> too. So I am asking yo > >>>>> u, could you please mention any > downsides of > >> using > >>>> Modula-3, in your experienc > >>>>> e? > >>>>> > >>>>> Of course, the non-existent language > community > >> has > >>>> already been mentioned as a > >>>>> major downside. > >>>>> And the lack of documentation. > >>>>> What about other issues, such as > compiler > >> efficiency? Or > >>>> interaction with fore > >>>>> ign libraries? > >>>>> > >>>>> Thanks > >>>>> > >>>>> Marresh > >>>> > >> > >> > > From dknoto at next.com.pl Tue Apr 24 20:28:05 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Tue, 24 Apr 2012 20:28:05 +0200 Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 Message-ID: <20120424202805.26f30211@wenus.next.com.pl> Hello All, I still have not resolved the problem of CM3 build from source on Fedora 16 x86_64. However, I installed Ubuntu 12.04 Beta i686 in VirtualBox and CM3 5.9.0 2012/04/13 compilation went smoothly. So I wonder how it compiles CM3 on x86_64 architecture? Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Tue Apr 24 21:18:09 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 24 Apr 2012 20:18:09 +0100 (BST) Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 In-Reply-To: <20120424202805.26f30211@wenus.next.com.pl> Message-ID: <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: I guess you are asking about how to produce a bootstrap image for cm3-min in LINUXAMD64, and the truth is that it uses the back-end for doing that but Jay knows the details. The front end doesn't know too much about about machine itself (or tries to ignore it) which makes it more portable code though not easier, so all the details might be related with m3gcc In any event, did you try the Fedora 16 package: http://pkgs.org/fedora-16/rpm-sphere-x86_64/cm3-5.8.6-11.1.x86_64.rpm.html It has a cm3 image maybe you could just scripts/do-cm3-std.sh buildship Thanks in advance --- El mar, 24/4/12, Dariusz Knoci?ski escribi?: > De: Dariusz Knoci?ski > Asunto: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > Para: m3devel at elegosoft.com > Fecha: martes, 24 de abril, 2012 13:28 > Hello All, > I still have not resolved the problem of CM3 build from > source on Fedora 16 > x86_64. However, I installed Ubuntu 12.04 Beta i686 in > VirtualBox and CM3 > 5.9.0 2012/04/13 compilation went smoothly. So I wonder how > it compiles CM3 on > x86_64 architecture? > Best regards > Dariusz Knoci?ski. > From jay.krell at cornell.edu Wed Apr 25 05:30:57 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 25 Apr 2012 03:30:57 +0000 Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 In-Reply-To: <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> References: <20120424202805.26f30211@wenus.next.com.pl>, <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: The information is buried here: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/doc/notes/porting.txt?rev=1.6;content-type=text%2Fplain - do a build of m3core, libm3, and the pieces that make up cm3, BUT stopping at the output of assembly -- not running the assembler and linker (scripts/python/boot1.py NEWTARGET) - package up (tar/gzip) the assembly files, as well as some .c files (done by boot1.py, sitting in the current working directory) - copy that to the target system (scp or ftp) - unpackage (untar/gzip) - cd step missing here - make - giving us cm3 - use that cm3 to then build the entire system on the new target missing instructions for the last step...but it is just to put cm3 in $PATH and run something in scripts...boot2.py maybe? - Jay > Date: Tue, 24 Apr 2012 20:18:09 +0100 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; dknoto at next.com.pl > Subject: Re: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > > Hi all: > I guess you are asking about how to produce a bootstrap image for cm3-min in LINUXAMD64, and the truth is that it uses the back-end for doing that but Jay knows the details. > > The front end doesn't know too much about about machine itself (or tries to ignore it) which makes it more portable code though not easier, so all the details might be related with m3gcc > > In any event, did you try the Fedora 16 package: > http://pkgs.org/fedora-16/rpm-sphere-x86_64/cm3-5.8.6-11.1.x86_64.rpm.html > > It has a cm3 image maybe you could just scripts/do-cm3-std.sh buildship > > Thanks in advance > > --- El mar, 24/4/12, Dariusz Knoci?ski escribi?: > > > De: Dariusz Knoci?ski > > Asunto: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > > Para: m3devel at elegosoft.com > > Fecha: martes, 24 de abril, 2012 13:28 > > Hello All, > > I still have not resolved the problem of CM3 build from > > source on Fedora 16 > > x86_64. However, I installed Ubuntu 12.04 Beta i686 in > > VirtualBox and CM3 > > 5.9.0 2012/04/13 compilation went smoothly. So I wonder how > > it compiles CM3 on > > x86_64 architecture? > > Best regards > > Dariusz Knoci?ski. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 25 15:08:03 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 25 Apr 2012 15:08:03 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, what can I say? > Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From dataf4l at gmail.com Wed Apr 25 18:08:28 2012 From: dataf4l at gmail.com (felipe valdez) Date: Wed, 25 Apr 2012 11:08:28 -0500 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: References: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size > per architecture. Of course there are various architectures, with their > various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you > expect one thread of your program to run on one CPU, second thread on > another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, > etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are > planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less > stressful, I mean, even the OS/400 has this feature of 128 pointers to > allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course > this would require more TYPE declarations and VAR as well (LADR, LVAR), but > could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, > what can I say? > Thanks in advance > > > -- 312-444-2124 Skype: f3l.headhunter Casa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 25 21:24:30 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 25 Apr 2012 20:24:30 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier? in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 25 23:37:43 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 25 Apr 2012 23:37:43 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <81486992-135C-4366-87A2-C126E45A7B68@m3w.org> Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor > > I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. > > Thanks in advance > > --- El mi?, 25/4/12, felipe valdez escribi?: > > De: felipe valdez > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Dragi?a Duri?" > CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 11:08 > > that is quite a response. > > > On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. >> So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. >> We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. >> >> So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. >> It must be done carefully aggressively because this is a changing world, what can I say? >> Thanks in advance > > > > > -- > 312-444-2124 > Skype: f3l.headhunter > Casa: 8043901 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 26 18:58:38 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Apr 2012 17:58:38 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <81486992-135C-4366-87A2-C126E45A7B68@m3w.org> Message-ID: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. Thank your? LONGINT? is easy just to say? LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER and LONGADDRESS<:ADDRESS so that the same function maps LONGINT ->ADDRESS Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. Thanks in advance --- El mi?, 25/4/12, Dragi?a Duri? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Daniel Alejandro Benavides D." CC: "felipe valdez" , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 16:37 Single "execution space" can span over various architectures ?in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen.? On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space.? It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier? in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Apr 26 19:44:18 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 26 Apr 2012 19:44:18 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Daniel, LONGINT and INTEGER are scalar types with no relation except one's values are subset of another. References to them are strongly typed in Modula-3 - meaning types are semantically different - but their representation is same as ADDRESS. In single address space you have all memory location addressable by same pointer type - ADDRESS. They can differ in alignment, depending on implementation decisions, but that is something else. Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied semantical informationis used where it is needed and it is not worry of language user unless she/he does something related to language environments other than Modula-3. Think RPC, OpenCL (GPU), ... On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, 8byte. Most 64bit platforms today are limited in number of address lines from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am sure it is limited to some number smaller than 64 on every 64bit platform today. But - that does not mean (Modula-3) language implementor will make PHYSADDRESS pointer type 6 bytes long. You probably can find such types in some experimental languages you are interested in. Good luck there, for/but I am not :). Unless my English-foreign is mismatched more than I think to your English-foreign, we are almost orthogonal in this discussion for some time. I checked, I am still writing to m3devel. Are you? :) dd On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. > In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. > Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER > and LONGADDRESS<:ADDRESS so that the same function maps > LONGINT ->ADDRESS > Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. > Thanks in advance > > > --- El mi?, 25/4/12, Dragi?a Duri? escribi?: > > De: Dragi?a Duri? > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Daniel Alejandro Benavides D." > CC: "felipe valdez" , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 16:37 > > Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. > > RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. > > On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. > > GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. > > It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. > > On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? >> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor >> >> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor >> >> I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. >> >> Thanks in advance >> >> --- El mi?, 25/4/12, felipe valdez escribi?: >> >> De: felipe valdez >> Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] >> Para: "Dragi?a Duri?" >> CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com >> Fecha: mi?rcoles, 25 de abril, 2012 11:08 >> >> that is quite a response. >> >> >> On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: >> As my first hands-on CPU was 6502, I think I remember a lot. >> >> ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. >> >> What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? >> >> On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. >>> So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. >>> We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. >>> >>> So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. >>> It must be done carefully aggressively because this is a changing world, what can I say? >>> Thanks in advance >> >> >> >> >> -- >> 312-444-2124 >> Skype: f3l.headhunter >> Casa: 8043901 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dataf4l at gmail.com Thu Apr 26 20:34:08 2012 From: dataf4l at gmail.com (felipe valdez) Date: Thu, 26 Apr 2012 13:34:08 -0500 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Message-ID: English, here, is the keyword. On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: > Daniel, > > LONGINT and INTEGER are scalar types with no relation except one's values > are subset of another. References to them are strongly typed in Modula-3 - > meaning types are semantically different - but their representation is same > as ADDRESS. In single address space you have all memory location > addressable by same pointer type - ADDRESS. They can differ in alignment, > depending on implementation decisions, but that is something else. > Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied > semantical informationis used where it is needed and it is not worry of > language user unless she/he does something related to language environments > other than Modula-3. Think RPC, OpenCL (GPU), ... > > On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, > 8byte. Most 64bit platforms today are limited in number of address lines > from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am > sure it is limited to some number smaller than 64 on every 64bit platform > today. But - that does not mean (Modula-3) language implementor will make > PHYSADDRESS pointer type 6 bytes long. You probably can find such types in > some experimental languages you are interested in. Good luck there, for/but > I am not :). > > Unless my English-foreign is mismatched more than I think to your > English-foreign, we are almost orthogonal in this discussion for some time. > I checked, I am still writing to m3devel. Are you? :) > > dd > > On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > In that sense, it's neither Physical or logical but process communications > are both (so hat's why its called Inter-process), but conceptually, you can > speak of that if that's what you mean. > In one of such architectures (as a Bus-oriented architecture > micro-processor) there are Logical Address (INTEGER), as the direction of a > physical processor bus ID, (where there is a one to one mapping LBID to > PBID) or a System Bus ID (ADDRESS), which identifies the location of a > kernel function. > Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because > you would want such a type of LBID address and function location, wouldn't > you? And then the location itself is and expressed by REF LONGINT<:REF > INTEGER > and LONGADDRESS<:ADDRESS so that the same function maps > LONGINT ->ADDRESS > Modula-3 type hierarchy does say that, doesn't it? This is because it is > contra variant type hierarchy. > Thanks in advance > > > --- El *mi?, 25/4/12, Dragi?a Duri? * escribi?: > > > De: Dragi?a Duri? > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Daniel Alejandro Benavides D." > CC: "felipe valdez" , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 16:37 > > Single "execution space" can span over various architectures in few ways. > Examples - RPC and GPU. > > RPC is nothing new and it does not presume multi architecture for single > object file. Nor it presumes single address space for various > components/processes. There is cross-process boundary where conversions > (data marshaling/unmarshalling) happen. > > On the other hand, GPU programming? No cross-process boundary in RPC > style, it almost looks like it is single executable - but it is not > "multiple CPU architecture per single object". Nor does it include single > address space for various object components included. > > GPU is an excellent example of what you are, very obliquely, hinting at. > But - it is not single object file for multiple architectures for single > address space. > > It is probably good idea for you to look at GPU's today to see what is > realistic in multi-architecture object generation/application. > > On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > Such as a module generating code, for sending both LONGINTs and > LONGADDRESSes through networks of wide processing units MCU (e.g array > processors)? > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor > > I guess I should tell you one, but there are too many to count examples, > in any case you would want to be truly multi platform and cross-porting > easier in general, rather than based in one base case, though Modula was > too good to make such things difficult in any case. If it serves to know > multitasking of DEC has been emulated through the AMD Bulldozer > microarchitecture with Array/Vector processor, etc. But it still needs more > cooperation (or at least using shared standards) on the industry to return > to those good days. > > Thanks in advance > > --- El *mi?, 25/4/12, felipe valdez * escribi?: > > > De: felipe valdez > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Dragi?a Duri?" > CC: "Daniel Alejandro Benavides D." , > m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 11:08 > > that is quite a response. > > > On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size > per architecture. Of course there are various architectures, with their > various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you > expect one thread of your program to run on one CPU, second thread on > another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, > etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are > planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less > stressful, I mean, even the OS/400 has this feature of 128 pointers to > allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course > this would require more TYPE declarations and VAR as well (LADR, LVAR), but > could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, > what can I say? > Thanks in advance > > > > > > -- > 312-444-2124 > Skype: f3l.headhunter > Casa: 8043901 > > > > > -- 312-444-2124 Skype: f3l.headhunter Casa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 26 20:56:59 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Apr 2012 19:56:59 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335466619.60883.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Well, I'm not so passing the fact that it is a computer more than a language what we are talking here. I was reading had several kinds of invariant type rules or covariant ones, but they found it was harder than they thought, so, I'm more type-orthogonal as such in Modula-3, the questions are more related to that than how to control language capabilities, which are very much simplified, however no many languages try to do the other part see what's in the machine. I think Dragisha's point is whether I reply myself, or just himself. So I don't care if anybody responses that's for sure, thought I won't do that my self. Thanks in advance --- El jue, 26/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: jueves, 26 de abril, 2012 13:34 English, here, is the keyword. On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: Daniel, LONGINT and INTEGER are scalar types with no relation except one's values are subset of another. References to them are strongly typed in Modula-3 - meaning types are semantically different - but their representation is same as ADDRESS. In single address space you have all memory location addressable by same pointer type - ADDRESS. They can differ in alignment, depending on implementation decisions, but that is something else. Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied semantical informationis used where it is needed and it is not worry of language user unless she/he does something related to language environments other than Modula-3. Think RPC, OpenCL (GPU), ... On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, 8byte. Most 64bit platforms today are limited in number of address lines from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am sure it is limited to some number smaller than 64 on every 64bit platform today. But - that does not mean (Modula-3) language implementor will make PHYSADDRESS pointer type 6 bytes long. You probably can find such types in some experimental languages you are interested in. Good luck there, for/but I am not :). Unless my English-foreign is mismatched more than I think to your English-foreign, we are almost orthogonal in this discussion for some time. I checked, I am still writing to m3devel. Are you? :) dd On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: Hi all: In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER and LONGADDRESS<:ADDRESS so that the same function maps LONGINT ->ADDRESS Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. Thanks in advance --- El mi?, 25/4/12, Dragi?a Duri? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Daniel Alejandro Benavides D." CC: "felipe valdez" , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 16:37 Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -- 312-444-2124Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 26 22:36:03 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 26 Apr 2012 16:36:03 -0400 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Message-ID: <20120426203603.GF4670@topoi.pooq.com> On Thu, Apr 26, 2012 at 01:34:08PM -0500, felipe valdez wrote: > English, here, is the keyword. > > > On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: > > > Daniel, > > > > On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, > > 8byte. Most 64bit platforms today are limited in number of address lines > > from CPU to memory, The rest can still be used within the processor for addressing virtual memory, which can be mapped to physical memory in a bewildering variety of ways, and can exceed physical RAM. -- hendrik From dragisha at m3w.org Thu Apr 26 23:31:02 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 26 Apr 2012 23:31:02 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <20120426203603.GF4670@topoi.pooq.com> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> <20120426203603.GF4670@topoi.pooq.com> Message-ID: <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> And still - ADDRESS type is 64bit. No 48, no 54 - but 64. As all (L|I)?LP64 pointer types are. On Apr 26, 2012, at 10:36 PM, Hendrik Boom wrote: > On Thu, Apr 26, 2012 at 01:34:08PM -0500, felipe valdez wrote: >> English, here, is the keyword. >> >> >> On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: >> >>> Daniel, >>> >>> On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, >>> 8byte. Most 64bit platforms today are limited in number of address lines >>> from CPU to memory, > > The rest can still be used within the processor for addressing virtual > memory, which can be mapped to physical memory in a bewildering variety > of ways, and can exceed physical RAM. > > -- hendrik From dabenavidesd at yahoo.es Fri Apr 27 04:50:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 27 Apr 2012 03:50:04 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <4F94513B.3060802@lcwb.coop> Message-ID: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Have you read this, if the answer is not, maybe you should, because it seems, this person knows that from the beginning there were problems in the language specification in thread semantics. https://groups.google.com/group/comp.arch/msg/880a211df40506ab?hl=en Rodney (and Mika), please make sure your code (implementation) is OK with standard semantics likewise I will do try to accept the Modula-3 semantics of threads are OK, hum, this could be fun, but, very hard, even Larch/Modula-3 might not be able to correct every error on it (so then I might say that is correct and safe, but anything SAFE). Of course there will always room running in circles but still is better to check if something else can be done properly, I mean, that you can't be safe-threaded for %100, can you? That's maybe why they drop the word SAFE for Modula-3 and that's good, they are honest. Thanks in advance --- El dom, 22/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 13:43 > > > On 04/22/2012 11:41 AM, Daniel Alejandro Benavides D. > wrote: > > Hi all: > > I'm more suspicious about the back needs over this > programs, since Win32 programs have worked OK, have they? So > I agree with you it's a matter of target implementation (not > UNSAFE world), but that's in m3gcc backend, isn't it? > > Similarly your code could be fixed to uniprocessor > semantics, so if this tests are OK either pthreads or > embedded M3 threads this is a clear symptom of that UP > semantics issue. > > In any case don't expect too many threads to do that > correctly, since any exception in them can't be managed by > Modula-3 RT > (by language definition) > > I'm not sure what you mean by this, but in my reading, the > language definition fully defines the interaction > between threads and exceptions. Exceptions can > propagate only within a thread. All the rules about > where > they propagate are in terms of either a statically enclosing > block or a dynamic parent, that is, the caller > of the current procedure. In both cases, it's strictly > within the thread where the exception was raised. > > If an exception ever got to the top of the call chain of its > thread, it would have to be the result of an > override of the apply method of the closure passed to > Thread.Fork. But that method has an empty RAISES > clause, so if that should happen, it would be a runtime > error, still within the thread. > > but at most in m3gcc semantics I believe so. DECthreads had > a nice mechanism to wrap it to Modula-3 style semantics > so it could be easier to offer that in a internal CM3 API. > > Thanks in advance > > > > > > --- El s?b, 21/4/12, Mika Nystrom > escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Jay K" > >> CC: m3devel at elegosoft.com > >> Fecha: s?bado, 21 de abril, 2012 18:36 > >> Jay K writes: > >>> 1) please elaborate > >> > >>> 2) We don't use longjmp as much any more=2C > but > >> get/set= > >>> /make/swapcontext on platforms that support > them.And > >> where we do use longjm= > >>> p=2C we have a more portable use than before -- > we no > >> longer hack on the jm= > >>> pbuf.There is a "trick" where you use > sigsetstack or > >> some such to get the s= > >>> tack pointer into the jmpbuf.Look at the code > and read > >> the paper referenced= > >>> . It is possible it didn't work on all > platforms. > >> But anyway=2C see #1.We'= > >>> d really prefer to just use pthreads.Hm. I'd > like to > >> look again at what pth= > >>> reads features we use -- I suspect > pthreads/Win32 can > >> beabstracted more thi= > >>> nly and the Modula-3 code > less-forked/more-shared. But > >> later.. - Jay> Fro= > >> > >> Sorry for the bad quote. My mailer still > lives in the > >> 7-bit world. > >> > >> In any case I was just mentioning as a problem with > the > >> current Modula-3 > >> implementation that the pthreads bindings are > buggy. I > >> would not (and > >> do not) use them for serious work. And user > threads > >> are, as we all know, > >> not ideal... > >> > >> Anybody who wants to investigate the matter can > start by > >> running the thread > >> testing program in m3core/tests/thread ... > Main.m3 is > >> fairly well documented. > >> > >> Mika > >> > > > From mika at async.caltech.edu Fri Apr 27 05:02:28 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Apr 2012 20:02:28 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: <20120427030228.B46BC1A205B@async.async.caltech.edu> "Daniel Alejandro Benavides D." writes: >Hi all: >Have you read this, if the answer is not, maybe you should, because it seem= >s, this person knows that from the beginning there were problems in the lan= >guage specification in thread semantics. >https://groups.google.com/group/comp.arch/msg/880a211df40506ab?hl=3Den > >Rodney (and Mika), please make sure your code (implementation) is OK with s= >tandard semantics likewise I will do try to accept the Modula-3 semantics o= >f threads are OK, hum, this could be fun, but, very hard, even Larch/Modula= >-3 might not be able to correct every error on it (so then I might say that= > is correct and safe, but anything SAFE). Of course there will always room = >running in circles but still is better to check if something else can be do= >ne properly, I mean, that you can't be safe-threaded for %100, can you? Tha= >t's maybe why they drop the word SAFE for Modula-3 and that's good, they ar= >e honest. >Thanks in advance I think the early specs of the Modula-3 threads were a bit loose, yes. I am pretty sure this was corrected for the formal verification. You can read about this in the Green Book, too. It is interesting that the author of the thread to which you refer essentially claims that C doesn't guarantee what one might think it claims. This would suggest that there may be things one shouldn't assume about pthreads. My Modula-3 code (in the thread tester program) is really nothing special. Please review it yourself and let me know if you find any issues. It's not particularly complicated... Mika From dragisha at m3w.org Fri Apr 27 09:41:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 09:41:29 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427030228.B46BC1A205B@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> Message-ID: <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> On Apr 27, 2012, at 5:02 AM, Mika Nystrom wrote: > > It is interesting that the author of the thread to which you refer essentially > claims that C doesn't guarantee what one might think it claims. This would suggest > that there may be things one shouldn't assume about pthreads. There is well known paper by Hans Boehm, possibly of interest to Daniel: http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html He cites Java Memory Model paper (also of possible interest here) and Boehm states problem is being addressed at moment. So, it's maybe only of historical interest now. > My Modula-3 code (in the thread tester program) is really nothing special. > Please review it yourself and let me know if you find any issues. > It's not particularly complicated? When I was implementing NPTL based threads for pm3 (around 2004) I met interesting issues with few thread programs in pm3 distribution. Those programs were written and tested with user space threads where order of thread execution was, for ready threads, always same. One was pp, as I remember... I am reading your source code just now. And one thing caught my eye: "Each type of thread starts by sleeping for a while, to give the other threads a chance to be created." Does not look like any guarantee to me, not in threaded application. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Apr 27 10:26:09 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 10:26:09 +0200 Subject: [M3devel] thread test (Mika) Message-ID: Did anyone run combinations of tests and found minimal test sets where breaks happen? I tried read,alloc and it breaks. read only does not. From small number of tests I performed, it looks like RTAllocator is real culprit here. Most breaks happens while allocating, even one I saw in FileRd.Init() while running -tests read,alloc . From dragisha at m3w.org Fri Apr 27 10:53:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 10:53:29 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: References: Message-ID: <765A576E-5D12-424A-BFFE-C06F51472A03@m3w.org> Oh, it does :). In FileRd.Init(). And during stop-the-world. IIRC, Tony mentioned allocation is solved by giving separate page to every thread to allocate new data from. It looks like straightforward method, and problem proof. But it also has border mooments where new pages are given to threads. Also a problem - world suspension from garbage collector. In less than 10 starts whole system deadlocked at least four times. On Apr 27, 2012, at 10:26 AM, Dragi?a Duri? wrote: > I tried read,alloc and it breaks. read only does not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Apr 27 19:13:40 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Apr 2012 10:13:40 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> Message-ID: <20120427171341.0D83E1A205E@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: ... >I am reading your source code just now. And one thing caught my eye: = >"Each type of thread starts by sleeping for a while, to give the other = >threads a chance to be created." Does not look like any guarantee to me, = >not in threaded application.=20= If the program prints "running" then all threads have been created. It eventually prints "running". Therefore all threads are created. --- The things wrong with CM3's pthreads threading are NOT subtle. The runtime completely freezes up, ctrl-C stops working, and other such things. Mika From dragisha at m3w.org Fri Apr 27 19:30:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 19:30:29 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427171341.0D83E1A205E@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> Message-ID: I do not doubt they are created. Probably not an issue with 3 threads here, 3 threads there, but it can be if one relies on "must be created after some arbitrary time" in any synchronization. I did, and SRC people did, at least in two places. I just don't see it as a good practice. BTW, your test is excellent stress machine. My laptops hate it, probably, till now :). Right now I am focused on an allocation race issue and I hope to fix it in few hours/a day. On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > ... >> I am reading your source code just now. And one thing caught my eye: = >> "Each type of thread starts by sleeping for a while, to give the other = >> threads a chance to be created." Does not look like any guarantee to me, = >> not in threaded application.=20= > > If the program prints "running" then all threads have been created. > > It eventually prints "running". > > Therefore all threads are created. > > --- > > The things wrong with CM3's pthreads threading are NOT subtle. > The runtime completely freezes up, ctrl-C stops working, and other > such things. > > Mika From mika at async.caltech.edu Fri Apr 27 19:49:48 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Apr 2012 10:49:48 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> Message-ID: <20120427174948.9BB191A205B@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >I do not doubt they are created. Probably not an issue with 3 threads = >here, 3 threads there, but it can be if one relies on "must be created = >after some arbitrary time" in any synchronization. I did, and SRC people = >did, at least in two places. I just don't see it as a good practice. Yes I have had that bug in my programs a few times. But to be really fair it's not that you're assuming that another thread is created by a certain time but you're assuming that it has done something by the time the first thread needs to do something else. In the examples of the sort you describe it is usually that the newly created thread has "had time to initialize" (in some way). My bug with this was of this nature: thread A: ... Thread.Fork(b)... wait... LOCK(b.mu) Thread B: ... self.mu := NEW(MUTEX) ... Oops! works on some threading implementations (user threads). Instant segfault on others! Have fun with the thread tester. It doesn't find any problems with user threads. I should probably have dug into the pthreads myself long ago but it's always so far down the todo list, and all my CM3 installations use user threads by necessity. If you can improve the pthreads I think it would make me much happier about CM3 in general. I still use PM3 as much as possible... Mika > >BTW, your test is excellent stress machine. My laptops hate it, = >probably, till now :). Right now I am focused on an allocation race = >issue and I hope to fix it in few hours/a day. > >On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: > >> =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >> ... >>> I am reading your source code just now. And one thing caught my eye: = >=3D >>> "Each type of thread starts by sleeping for a while, to give the = >other =3D >>> threads a chance to be created." Does not look like any guarantee to = >me, =3D >>> not in threaded application.=3D20=3D >>=20 >> If the program prints "running" then all threads have been created. >>=20 >> It eventually prints "running". >>=20 >> Therefore all threads are created. >>=20 >> --- >>=20 >> The things wrong with CM3's pthreads threading are NOT subtle. >> The runtime completely freezes up, ctrl-C stops working, and other >> such things. >>=20 >> Mika From dragisha at m3w.org Fri Apr 27 20:13:20 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 20:13:20 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> References: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> Message-ID: This particular deadlock/fix is observed and fixed for AMD64_LINUX. First change is just because it is same pattern. I ddidn't check if that code is used at all. Second change is our fix. With this, Mika's threadtest -tests alloc works. This is very probably fix for lots of situations tripped by his test and also for applications with heavy heap usage. dd p.s. Olaf/Michael, please teach me (again) how to commit this . It was long time since I commited anything to CVS :). Index: src/thread/PTHREAD/ThreadPThread.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v retrieving revision 1.259 diff -U 2 -r1.259 ThreadPThread.m3 --- src/thread/PTHREAD/ThreadPThread.m3 16 Jan 2011 21:25:21 -0000 1.259 +++ src/thread/PTHREAD/ThreadPThread.m3 27 Apr 2012 18:06:43 -0000 @@ -782,4 +782,5 @@ <*ASSERT act.state # ActState.Starting*> IF act.state # ActState.Stopped THEN + SetState(act, ActState.Stopping); SignalThread(act); INC(newlySent); @@ -971,4 +972,5 @@ <*ASSERT act.state # ActState.Starting*> IF act.state # ActState.Stopped THEN + SetState(act, ActState.Stopping); SignalThread(act); INC(newlySent); On Apr 27, 2012, at 3:04 PM, Antony Hosking wrote: > Platform? > Thread stack dump? > I assume it is a deadlock. > If not deadlock then what? > Diagnosis would then allow us to fix. > > Sent from my iPhone > > On Apr 27, 2012, at 3:26 AM, Dragi?a Duri? wrote: > >> Did anyone run combinations of tests and found minimal test sets where breaks happen? >> >> I tried read,alloc and it breaks. read only does not. >> >> From small number of tests I performed, it looks like RTAllocator is real culprit here. Most breaks happens while allocating, even one I saw in FileRd.Init() while running -tests read,alloc . From dragisha at m3w.org Fri Apr 27 21:30:16 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 21:30:16 +0200 Subject: [M3devel] Mika's thread test, -tests read Message-ID: Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. dd === (gdb) bt #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) at ../src/runtime/common/RTCollector.m3:1091 #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, thread=) at ../src/runtime/common/RTAllocator.m3:367 #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) info threads Id Target Id Frame * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 (gdb) thr 3 From wagner at elegosoft.com Fri Apr 27 22:13:35 2012 From: wagner at elegosoft.com (mail.elegosoft.com) Date: Fri, 27 Apr 2012 22:13:35 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: References: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> Message-ID: <20120427221335.699cc2ed.wagner@elegosoft.com> On Fri, 27 Apr 2012 20:13:20 +0200 Dragi?a Duri? wrote: > This particular deadlock/fix is observed and fixed for AMD64_LINUX. First change is just because it is same pattern. I ddidn't check if that code is used at all. Second change is our fix. > > With this, Mika's threadtest -tests alloc works. This is very probably fix for lots of situations tripped by his test and also for applications with heavy heap usage. > > dd > > p.s. Olaf/Michael, please teach me (again) how to commit this . It was long time since I commited anything to CVS :). If you've got the change in a workspace checked out via cvs/ssh, you just need to call `cvs commit' or `cvs commit -m "some meaningful log message"'. I assume that you have ssh access to m3.elegosoft.com. If not, Mike can set it up for you if you provide a key, or I can commit your changes if there are only a few of them. You may want to read http://www.elegosoft.com/en/solutions/modula-3/cvs-ssh-access.html if you haven't got ssh access yet. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Apr 27 22:21:22 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 27 Apr 2012 16:21:22 -0400 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> <20120426203603.GF4670@topoi.pooq.com> <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> Message-ID: <20120427202122.GF30181@topoi.pooq.com> On Thu, Apr 26, 2012 at 11:31:02PM +0200, Dragi?a Duri? wrote: > And still - ADDRESS type is 64bit. No 48, no 54 - but 64. As all (L|I)?LP64 pointer types are. Exactly! -- hendrik From dragisha at m3w.org Fri Apr 27 22:51:42 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 22:51:42 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: Message-ID: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> Another one, pretty "clean". Other threads are using their local memory, nothing shared execpt, of course, heap. Also, no visible pattern (yet) in other thread states/stacks when one of them breaks at this point. This, an RTCollector.Move() reported earlier, are two breaks in this test. === Creating nxread threads...[New Thread 0x7ffff7fd1700 (LWP 24756)] [New Thread 0x7ffff77d0700 (LWP 24757)] [New Thread 0x7ffff6fcf700 (LWP 24758)] done running...printing oldest/median age/newest ..........laziest thread is 0/0/0 (tests: nxread 0/0/0) ..........laziest thread is 0/0/0 (tests: nxread 0/0/0) . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7fd1700 (LWP 24756)] 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 44 IF (rd.buff = NIL) THEN (gdb) bt #0 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 #1 0x000000000041831d in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 #2 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 #3 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #4 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #5 0x0000003bed807d90 in start_thread (arg=0x7ffff7fd1700) at pthread_create.c:309 #6 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) info threads Id Target Id Frame 4 Thread 0x7ffff6fcf700 (LWP 24758) "threadtest" UnsafeRd__FastGetChar (rd=) at ../src/rw/Rd.m3:44 3 Thread 0x7ffff77d0700 (LWP 24757) "threadtest" 0x000000000044f405 in ThreadPThread__LockMutex (m=) at ../src/thread/PTHREAD/ThreadPThread.m3:115 * 2 Thread 0x7ffff7fd1700 (LWP 24756) "threadtest" 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 1 Thread 0x7ffff7fd3700 (LWP 24752) "threadtest" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 (gdb) On Apr 27, 2012, at 9:30 PM, Dragi?a Duri? wrote: > Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. From dragisha at m3w.org Fri Apr 27 23:11:51 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 23:11:51 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> Message-ID: <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Yes. [New Thread 0x7ffff7fd1700 (LWP 24695)] [New Thread 0x7ffff77d0700 (LWP 24696)] [New Thread 0x7ffff6fcf700 (LWP 24697)] done running...printing oldest/median age/newest . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff77d0700 (LWP 24696)] 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) bt ... I am using unchanged thread test from m3core/tests/thread with only -tests nxread as argument. On AMD64_LINUX, mostly, although I had breaks on AMD64_DARWIN too. I'll print future breaks with C stacks. dd On Apr 27, 2012, at 11:03 PM, Antony Hosking wrote: > Is this one a SIGSEGV? > > On Apr 27, 2012, at 3:30 PM, Dragi?a Duri? wrote: > >> Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. >> >> dd >> === >> (gdb) bt >> #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) >> at ../src/runtime/common/RTCollector.m3:409 >> #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) >> at ../src/runtime/common/RTHeapMap.m3:202 >> #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:62 >> #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 >> #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) >> at ../src/runtime/common/RTCollector.m3:1091 >> #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 >> #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >> #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, >> thread=) at ../src/runtime/common/RTAllocator.m3:367 >> #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 >> #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 >> #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 >> #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 >> #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 >> #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 >> #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 >> #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 >> #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 >> #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 >> (gdb) info threads >> Id Target Id Frame >> * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, >> cp=) at ../src/runtime/common/RTCollector.m3:409 >> 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> (gdb) thr 3 >> > From dragisha at m3w.org Sat Apr 28 08:49:25 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 08:49:25 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Message-ID: What is stack redzone? Undetected stack overflows or almost overflows? It's not only AMD64_* if it's any consolation: :) frodo:dragisha/pts/0: m3/thread/src% ../LINUXLIBC6/threadtest -tests read,alloc Writing file...done Creating read threads...done Creating alloc threads...done running...printing oldest/median age/newest . *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80792f0 = Move + 0x54 in ../src/runtime/common/RTCollector.m3 *** On Apr 27, 2012, at 11:34 PM, Antony Hosking wrote: > I wonder if we are not seeing the stack redzone on x86-64 and so losing references. > > On Apr 27, 2012, at 5:11 PM, Dragi?a Duri? wrote: > >> Yes. >> [New Thread 0x7ffff7fd1700 (LWP 24695)] >> [New Thread 0x7ffff77d0700 (LWP 24696)] >> [New Thread 0x7ffff6fcf700 (LWP 24697)] >> done >> running...printing oldest/median age/newest >> . >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7ffff77d0700 (LWP 24696)] >> 0x00000000004374e5 in RTCollector__Move (self=, cp=) >> at ../src/runtime/common/RTCollector.m3:409 >> 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; >> (gdb) bt >> ... >> >> I am using unchanged thread test from m3core/tests/thread with only -tests nxread as argument. On AMD64_LINUX, mostly, although I had breaks on AMD64_DARWIN too. >> >> I'll print future breaks with C stacks. >> >> dd >> >> On Apr 27, 2012, at 11:03 PM, Antony Hosking wrote: >> >>> Is this one a SIGSEGV? >>> >>> On Apr 27, 2012, at 3:30 PM, Dragi?a Duri? wrote: >>> >>>> Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. >>>> >>>> dd >>>> === >>>> (gdb) bt >>>> #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) >>>> at ../src/runtime/common/RTCollector.m3:409 >>>> #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:202 >>>> #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:62 >>>> #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:57 >>>> #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:57 >>>> #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 >>>> #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) >>>> at ../src/runtime/common/RTCollector.m3:1091 >>>> #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 >>>> #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >>>> #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>>> #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>>> #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, >>>> thread=) at ../src/runtime/common/RTAllocator.m3:367 >>>> #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 >>>> #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 >>>> #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 >>>> #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 >>>> #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 >>>> #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 >>>> #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 >>>> #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 >>>> #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 >>>> #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 >>>> (gdb) info threads >>>> Id Target Id Frame >>>> * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, >>>> cp=) at ../src/runtime/common/RTCollector.m3:409 >>>> 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> (gdb) thr 3 >>>> >>> >> > From dragisha at m3w.org Sat Apr 28 09:57:59 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 09:57:59 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Message-ID: RTFM helps, as always? No, I don't think it is redzone. BUT. One run: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4200 thread 0x10f] 0x0000000100037360 in RTCollector__Move (self=Cannot access memory at address 0xffffffffffffff77 ) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) ===== Next run: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4204 thread 0x40f] 0x0000000100017e6b in FileRd__Init (rd=Cannot access memory at address 0xffffffffffffffa7 ) at ../src/rw/FileRd.m3:44 44 IF (rd.buff = NIL) THEN ===== Next: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4207 thread 0x1703] 0x0000000100037360 in RTCollector__Move (self=Cannot access memory at address 0xffffffffffffff77 ) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) p hdr Cannot access memory at address 0xffffffffffffffdf << local variable ===== And so on? Break in FileRd.Init() happens after AllocTraced() takes LongAlloc() route. Break in Move happens along AllocTraced->CollectEnough. Interesting thing - previous call to AllocTraced took a LongAlloc() route. C trace, in Move() break: ===== (gdb) set lang c (gdb) bt #0 0x0000000100037360 in RTCollector__Move (self=0x100953c60, cp=0x100e50018) at ../src/runtime/common/RTCollector.m3:409 #1 0x00000001000358ca in RTHeapMap__Walk (x=0x0, pc=0x1009c0028, v=0x100098a88) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x0000000100034fb2 in RTHeapMap__DoWalkRef (t=0x1, a=0x100083de8, v=0x1009c0028) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100087898, a=0x100084848, v=0x1009c0018) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100d09a30, a=0x100084a48, v=0x1009c0018) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x0000000100034f21 in RTHeapMap__WalkRef (h=0x2018, v=0x1009c0010) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x000000010003986a in RTCollector__CleanBetween (h=0x0, he=0x1009c0010, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091 #7 0x0000000100039674 in RTCollector__CleanPage (page=0x1009d0000) at ../src/runtime/common/RTCollector.m3:1064 #8 0x0000000100038dd5 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #9 0x0000000100038532 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #10 0x000000010003820f in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 ===== Lines can differ, as I've put few RTIO.* lines in RTAllocator/Collector. On Apr 28, 2012, at 8:49 AM, Dragi?a Duri? wrote: > What is stack redzone? Undetected stack overflows or almost overflows? From dragisha at m3w.org Sat Apr 28 10:02:40 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 10:02:40 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> References: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> Message-ID: (this and previous email - AMD64_DARWIN) r -tests read,alloc @M3paranoidgc Starting program: /Users/dragisha/m3/thread/AMD64_DARWIN/threadtest -tests read,alloc @M3paranoidgc ... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4249 thread 0x1703] 0x000000010003bba1 in RTCollector__RefSanityCheck (v=Cannot access memory at address 0xffffffffffffffa7 ) at ../src/runtime/common/RTCollector.m3:1702 1702 tc := h.typecode; (gdb) set lang c (gdb) bt #0 0x000000010003bba1 in RTCollector__RefSanityCheck (v=0x0, cp=0x100980958) at ../src/runtime/common/RTCollector.m3:1702 #1 0x00000001000358ca in RTHeapMap__Walk (x=0x0, pc=0x100e20028, v=0x100098a88) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x0000000100034fb2 in RTHeapMap__DoWalkRef (t=0x1, a=0x100083de8, v=0x100e20028) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100087898, a=0x100084848, v=0x100e20018) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100e0f9f0, a=0x100084a48, v=0x100e20018) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x0000000100034f21 in RTHeapMap__WalkRef (h=0x2018, v=0x100e20010) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x000000010003b8dc in RTCollector__SanityCheck (self=0x100e20000) at ../src/runtime/common/RTCollector.m3:1660 #7 0x000000010003b618 in RTCollector__After (self=0x100e0fad0) at ../src/runtime/common/RTCollector.m3:1630 #8 0x0000000100035d35 in RTHeapRep__InvokeMonitors (before=0 '\0') at ../src/runtime/common/RTHeapRep.m3:59 #9 0x0000000100039305 in RTCollector__CollectSomeInStateFive () at ../src/runtime/common/RTCollector.m3:984 #10 0x000000010003856e in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:725 #11 0x000000010003820f in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #12 0x0000000100033d73 in RTAllocator__AllocTraced (dataSize=0, dataAlignment=8216, thread=0x8) at ../src/runtime/common/RTAllocator.m3:368 #13 0x0000000100033692 in RTAllocator__GetOpenArray (def=0x200026, s=0x100087898) at ../src/runtime/common/RTAllocator.m3:297 #14 0x00000001000329b2 in RTHooks__AllocateOpenArray (defn=0x100f2d468, s=0x100087898) at ../src/runtime/common/RTAllocator.m3:144 #15 0x0000000100002b32 in Main__AApply (cl=0x100e0fd80) at ../src/Main.m3:283 #16 0x0000000100050849 in ThreadPThread__RunThread (me=0x1703) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #17 0x000000010005050e in ThreadPThread__ThreadBase (param=0x100a01b00) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #18 0x00007fff84f908bf in _pthread_start () #19 0x00007fff84f93b75 in thread_start () This time - previous branch was not AllocTraced()->LongAlloc() dd On Apr 27, 2012, at 11:06 PM, Antony Hosking wrote: > Similarly, I suspect rd is corrupted on line 44 of FileRd.m3. > These all point to a collector bug. > Need to run with @M3paranoidgc to trigger the bug at collection time rather than later on when the mutator code is running. From dragisha at m3w.org Sat Apr 28 10:09:32 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 10:09:32 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> Message-ID: <6B6C6981-55E6-45ED-B2A6-E86A0853A23C@m3w.org> With paranoidgc errors are happening in/after AllocTraced() calls happening after AllocTraced() going short route. But not all happen here. I caught few in FileRd.Init(), again. On Apr 28, 2012, at 10:02 AM, Dragi?a Duri? wrote: > r -tests read,alloc @M3paranoidgc > Starting program: /Users/dragisha/m3/thread/AMD64_DARWIN/threadtest -tests read,alloc @M3paranoidgc > ... > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 > [Switching to process 4249 thread 0x1703] > 0x000000010003bba1 in RTCollector__RefSanityCheck (v=Cannot access memory at address 0xffffffffffffffa7 > ) at ../src/runtime/common/RTCollector.m3:1702 > 1702 tc := h.typecode; -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 28 11:10:42 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Apr 2012 09:10:42 +0000 Subject: [M3devel] ProcessEachStack duplicates StopWorld/StartWorld? Message-ID: Tony, can ProcessEachStack not have all the stop/start code duplicated and instead look more like: StopWorld act := me.next; WHILE act # me DO ProcessOther(act) act := act.next; END StartWorld ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 28 11:29:11 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 11:29:11 +0200 Subject: [M3devel] ProcessEachStack duplicates StopWorld/StartWorld? In-Reply-To: References: Message-ID: I think it can. I've fixed that loop also, just to be sure :). On Apr 28, 2012, at 11:10 AM, Jay K wrote: > Tony, can ProcessEachStack not have all the stop/start code > duplicated and instead look more like: > > > StopWorld > act := me.next; > WHILE act # me DO > ProcessOther(act) > act := act.next; > END > StartWorld > > > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 28 15:14:55 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 15:14:55 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> Message-ID: <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> Mika said it does not happen with user threads. But he also said he is using pm3 mostly? So question is - did he run it with cm3, any version, with user threads. What are build parameters for cm3 with user threads? On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > That means it is even more serious. > Can we verify that it only happens with pthread threading? > > Sent from my iPad > > On Apr 28, 2012, at 1:49 AM, Dragi?a Duri? wrote: > >> It's not only AMD64_* if it's any consolation: :) From mika at async.caltech.edu Sat Apr 28 18:50:38 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 28 Apr 2012 09:50:38 -0700 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> Message-ID: <20120428165038.E59451A205B@async.async.caltech.edu> Yes I have done it with user threads on CM3. (BTW, that is the configuration I always use on Darwin and Linux for "work".) There are a few ways of doing the configuration. The main thing is that the file m3-libs/m3core/src/thread/m3makefile contains the code >>> include_dir ("Common") if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") include_dir ("WIN32") else if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) include_dir("PTHREAD") else include_dir (OS_TYPE) end end <<< NO_USER_THREADS and USE_PTHREADS come from the config file. Mika =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Mika said it does not happen with user threads. But he also said he is = >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = >version, with user threads. > >What are build parameters for cm3 with user threads?=20 > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > >> That means it is even more serious. >> Can we verify that it only happens with pthread threading? >>=20 >> Sent from my iPad >>=20 >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > wrote: >>=20 >>> It's not only AMD64_* if it's any consolation: :) From jay.krell at cornell.edu Sun Apr 29 01:59:47 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Apr 2012 23:59:47 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <20120428165038.E59451A205B@async.async.caltech.edu> References: , <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com>, <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org>, , , <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com>, <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org>, <20120428165038.E59451A205B@async.async.caltech.edu> Message-ID: To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. - Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sun Apr 29 19:40:51 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 29 Apr 2012 18:40:51 +0100 (BST) Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: Message-ID: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> Iconic Modula-3 threads would be user-level transparent threads of machine threads, but then you would need threading system to cope with. I believe that current system is OK respect PTHREADS as much as is, this is specially true if there isn't one application that use threads of machine-level likely easier than other application users of them (see for example cvsup), cvsup has strong reliance on network idle times to decompress and use disk files to continue downloading over a two channel communication space, if you have server-side SMP-threads, then it's not easier to use them accordingly, because you still may have lower latencies queuing them and proportionately them to your users (your system will queue them as FIFO), but while your threads might finish connection faster, other user-level threads might need them more time to finish so they will be locked until (due network considerations and system dequeuing) clients get their messages off-time also, which is not fair if you are downloading small bits of code after other's longer chunks of code. I learned this while downloading with user-level threads and faster than with network same conditions and same machine with p-threads'ed systems longer finish time. Now this is counter-wise effect, as I got this while downloading from user-level thread system. Thanks in advance Thanks in advance http://modula3.elegosoft.com/cm3/ --- El s?b, 28/4/12, Jay K escribi?: De: Jay K Asunto: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? Para: "Mika Nystrom" , dragisha at m3w.org CC: "m3devel" Fecha: s?bado, 28 de abril, 2012 18:59 To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. ?- Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 29 23:01:39 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Apr 2012 21:01:39 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <26C159EB-EDC6-453C-A8EE-2F1AAAF0E170@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> <20120428165038.E59451A205B@async.async.caltech.edu> , <26C159EB-EDC6-453C-A8EE-2F1AAAF0E170@gmail.com> Message-ID: Ok, I can't argue with that. - Jay CC: mika at async.caltech.edu; dragisha at m3w.org; m3devel at elegosoft.com From: antony.hosking at gmail.com Subject: Re: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? Date: Sat, 28 Apr 2012 19:58:28 -0500 To: jay.krell at cornell.edu I'm just being conservative. Let's fix bugs before refactoring further. Sent from my iPad On Apr 28, 2012, at 6:59 PM, Jay K wrote: To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. - Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 29 23:11:36 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 29 Apr 2012 17:11:36 -0400 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <20120429211136.GA31736@topoi.pooq.com> On Sun, Apr 29, 2012 at 06:40:51PM +0100, Daniel Alejandro Benavides D. wrote: > (see for example cvsup), cvsup has strong reliance on network idle > times Speaking of cvsup, I seem to remember it stopped working, perhaps because of thread implementatino problems. Is it back in order yet? -- hendrik From jay.krell at cornell.edu Sun Apr 29 23:20:58 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Apr 2012 21:20:58 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <20120429211136.GA31736@topoi.pooq.com> References: , <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com>, <20120429211136.GA31736@topoi.pooq.com> Message-ID: We fixed it a long time ago. The problem was: Usually fork() is followed very soon by exec(). i.e. the way Posix programs (processes) often run sub-programs (processes) is via fork and exec. This is ok. No problem. However there is another pattern of use of fork where "servers" call fork for each "client". They don't exec. It is something like creating a thread. Except that everything is read-only/copy-on-write, not really shared. This is useful if servers have an expensive initialization, and don't need to share per-client. Cvsup does that. When fork is not followed by exec, whatever Modula-3 user threads existed in the "parent" process, still exist in the "child" process. The same is NOT true with pthreads. cvsup depended on the threads all surviving fork. We fixed cvsup to recreate its threads in the child process, and to fix user threads to NOT have threads survive fork, except the one calling fork. This highlighted other problems -- the existance of and possible need to use pthread_atfork. I'm not really explaining it all, but mostly. Look up pthread_atfork. - Jay > Date: Sun, 29 Apr 2012 17:11:36 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? > > On Sun, Apr 29, 2012 at 06:40:51PM +0100, Daniel Alejandro Benavides D. wrote: > > (see for example cvsup), cvsup has strong reliance on network idle > > times > > Speaking of cvsup, I seem to remember it stopped working, perhaps > because of thread implementatino problems. Is it back in order yet? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 29 23:49:22 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 29 Apr 2012 16:49:22 -0500 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427174948.9BB191A205B@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> <20120427174948.9BB191A205B@async.async.caltech.edu> Message-ID: <4F9DB762.3030608@lcwb.coop> On 04/27/2012 12:49 PM, Mika Nystrom wrote: > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >> I do not doubt they are created. Probably not an issue with 3 threads = >> here, 3 threads there, but it can be if one relies on "must be created = >> after some arbitrary time" in any synchronization. I did, and SRC people = >> did, at least in two places. I just don't see it as a good practice. > > Yes I have had that bug in my programs a few times. > > But to be really fair it's not that you're assuming that another > thread is created by a certain time but you're assuming that it has > done something by the time the first thread needs to do something else. > In the examples of the sort you describe it is usually that the newly > created thread has "had time to initialize" (in some way). My bug with > this was of this nature: > > thread A: > > ... Thread.Fork(b)... wait... LOCK(b.mu) > > Thread B: > > ... self.mu := NEW(MUTEX) ... > > Oops! works on some threading implementations (user threads). > Instant segfault on others! As I recall, this is the reason Thread.T <: MUTEX. Otherwise, there would be chicken-egg cases like this where you need a mutex to protect the allocation of a mutex and have no dependable way to get one. > > Have fun with the thread tester. It doesn't find any problems with > user threads. > > I should probably have dug into the pthreads myself long ago but it's > always so far down the todo list, and all my CM3 installations use user > threads by necessity. If you can improve the pthreads I think it would > make me much happier about CM3 in general. I still use PM3 as much as > possible... > > Mika > > >> >> BTW, your test is excellent stress machine. My laptops hate it, = >> probably, till now :). Right now I am focused on an allocation race = >> issue and I hope to fix it in few hours/a day. >> >> On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: >> >>> =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>> ... >>>> I am reading your source code just now. And one thing caught my eye: = >> =3D >>>> "Each type of thread starts by sleeping for a while, to give the = >> other =3D >>>> threads a chance to be created." Does not look like any guarantee to = >> me, =3D >>>> not in threaded application.=3D20=3D >>> =20 >>> If the program prints "running" then all threads have been created. >>> =20 >>> It eventually prints "running". >>> =20 >>> Therefore all threads are created. >>> =20 >>> --- >>> =20 >>> The things wrong with CM3's pthreads threading are NOT subtle. >>> The runtime completely freezes up, ctrl-C stops working, and other >>> such things. >>> =20 >>> Mika > From dragisha at m3w.org Fri Apr 6 21:38:30 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 6 Apr 2012 21:38:30 +0200 Subject: [M3devel] cm3ide, ESC, cm3jvm(?) Message-ID: <1DDF651B-C60C-45A3-8DF4-005216FE67ED@m3w.org> Recently I found time to get cm3ide up? My thanks to Bill, Farshad, Randy and Olaf! Also, I see there is ESC now in cm3 /... Can we expect complete version, or do we already have that? How to use? Also II - is there any chance to get cmass JVM opensourced? I have many ideas how to make that useful.. TIA, dd From dabenavidesd at yahoo.es Fri Apr 6 22:43:35 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 6 Apr 2012 21:43:35 +0100 (BST) Subject: [M3devel] cm3ide, ESC, cm3jvm(?) In-Reply-To: <1DDF651B-C60C-45A3-8DF4-005216FE67ED@m3w.org> Message-ID: <1333745015.46036.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: nice idea, JVM + CMM3 is nice product. ESC was a nice idea too, but if you see its results in Java I don't know if it has been a "market" success (lost type checking information can make a better realization of it, like in casting errors, etc), although it was not intended for that but to be useful in the research area of CS, specially education. I would like the idea of using typed interpretation of objects on it for Modular checking of other jvm mechanics (though Java Object Model is inherently different from that of a Module-oriented VM, but since it's almost an operating system): for instance a new type-safe object make of Objects, but in that sense, you have (mandatory) to be sound to tough compiler purists specially in Java attempt that but still not quite like Modula-3 Module semantics purity. So it's hard to talk and hard technology to crasp on, but sure, none of them will be disliked by such a beast, anyone agree? Thanks in advance --- El vie, 6/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] cm3ide, ESC, cm3jvm(?) > Para: "m3devel" > Fecha: viernes, 6 de abril, 2012 14:38 > Recently I found time to get cm3ide > up? My thanks to Bill, Farshad, Randy and Olaf! > > Also, I see there is ESC now in cm3 /... Can we expect > complete version, or do we already have that? How to use? > > Also II - is there any chance to get cmass JVM opensourced? > I have many ideas how to make that useful.. > > TIA, > dd > > From dabenavidesd at yahoo.es Thu Apr 12 23:09:00 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 12 Apr 2012 22:09:00 +0100 (BST) Subject: [M3devel] A Baby Modula-3 Operating Environment hosted on SPIN OS for Language Researchers Message-ID: <1334264940.21694.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I was reading about Meta-Environments (and finding some sort of it for Modula-3) and found MetaBETA (Scandinavian school OO programming language), that uses Dynamic linking and loading of SPIN mechanism for itself: http://www.daimi.au.dk/PB/506/PB-506.pdf Can't we make our own flavor for it? Meta-BM3. We could create the drivers needed for it in a Modula-3 fashion (actually as it happens the side effects of UNSAFE modules could be verified by dynamic type tests and/or verified assembly like in a JVM-style ?-code not to corrupt the verified ones) or by memory watchdog as I believe Alpha architecture had a nice feature to warn against unwanted access on certain memory regions, hadn't it? Thanks in advance From penn43 at gmx.com Thu Apr 19 00:10:24 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Thu, 19 Apr 2012 00:10:24 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120418221024.27330@gmx.com> Dear Modula-3 developers, I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. I hope you can help me clarify some points and dispel some doubts. The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. I thank you in advance. Best regards, Marresh P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). From rcolebur at SCIRES.COM Thu Apr 19 01:13:26 2012 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 18 Apr 2012 19:13:26 -0400 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: Marresh: I've programmed in a number of different languages. For me, I've found that Modula-3 is the best for most of what I do. Further, I've found that the concepts in Modula-3 help you think through things in a more complete manner, thereby making you a better programmer. When I've been forced to use other languages, I've often found myself starting out in Modula-3 and then translating to the other language once the main concepts are defined. Just because Modula-3 is touted as a systems programming language doesn't mean it is too complex for simpler projects; however, if you are only wanting to write very simple, independent programs that won't ever have any parts reused anywhere else, you may find the initial discipline of interfaces and implementations a bit verbose. The language itself is really quite compact, given its power, and the concepts are straightforward and don't throw you curve balls. I can't really comment much about Oberon as I haven't used it much. As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. I'm not sure if anyone has done any recent bindings to GUI toolkits. Hope this helps. --Randy Coleburn -----Original Message----- From: penn43 at gmx.com [mailto:penn43 at gmx.com] Sent: Wednesday, April 18, 2012 6:10 PM To: m3devel at elegosoft.com Subject: [M3devel] Modula-3 questions Dear Modula-3 developers, I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. I hope you can help me clarify some points and dispel some doubts. The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. I thank you in advance. Best regards, Marresh P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). From mika at async.caltech.edu Thu Apr 19 02:25:50 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 18 Apr 2012 17:25:50 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: <20120419002550.798361A205B@async.async.caltech.edu> penn43 at gmx.com writes: ... >P.S. is the creation and maintenance of module interfaces all that trouble? I >read somewhere that it is a pain, and that the inconvenience of it would only >be paid off when one has to manage large projects (which is not my case). I personally find the Modula-3 interface design to be one of the best parts of the language. It would maybe be nice if it had more levels of qualification, like Java, but that's a minor issue. The way that it's almost impossible to get name clashes is a much bigger advantage. And you find that the small effort required to type your procedure prototypes pays off rather quickly... Finally, I could ask you what kind of programming you intend to do that you are certain won't eventually turn into large projects :-) Mika From dabenavidesd at yahoo.es Thu Apr 19 03:52:27 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 02:52:27 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> Message-ID: <1334800347.21677.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Threads are common use of Modula-3 Standard Interfaces because basically Modula-3 was born in Modula-2+ programming environments of multi-processor or mainframes (it was a kind of ahead of its time for real). If you don't need Thread I guess you don't want to use several options like OS support (like Systems programming) and stuff, Modula-3 has its own environment for safe-threads (embedded) threads, though its use is not mandatory and not successful in any SMP environment (by default nowadays). GUIs are not mandatory supported and constructed bottom up, if you want a new GUI system, you want a threaded one (that's Modula-2+ supposition since, you want not much overhead so be alerted in any event or for stronger distributed multi-window system like current Trestle is designed). In any event, there is a KDevelop project of Modula-3 but that was quite some time ago. Though there is some support in Gtk, but again talking about a small size project that is overkilling, Gtk library dependencies on C makes a not want to develop for them, so avoid them right? Simple languages are characterized by the smaller language definitions, this the case with C++, C, Java (the last two are called 'simple'), but spirit of Oberon was the same foundation of Modula-3, simpler is better, cleaner and still good support for better programming productivity (say Oberon for ?-controllers and small-footprint environments) so it gets rid of everything it can be too onerous (including big libraries and etc, but this days libraries and smaller memories are bigger than those days, so) Also Oberon was designed for compiler designer, so you do the math. Thanks in advance --- El mi?, 18/4/12, penn43 at gmx.com escribi?: > De: penn43 at gmx.com > Asunto: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 18 de abril, 2012 17:10 > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. > I have already had a look at the language, and it certainly > looks interesting. However, I still have some misgivings > about starting learning Modula-3, since it would be a > considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some > doubts. > > The first point is that I would neither be working on large > projects, nor doing systems programming. I understand these > were the two major strengths of Modula-3, but neither would > be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > Secondly, could you please help me understand what are the > reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > So, again, keeping in mind that I don't need the advanced > features mentioned above, nor multithreading, does it make > any sense for me to choose Modula-3 instead of Oberon, or > Object Pascal? > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces > all that trouble? I read somewhere that it is a pain, and > that the inconvenience of it would only be paid off when one > has to manage large projects (which is not my case). > > From dragisha at m3w.org Thu Apr 19 10:36:56 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Apr 2012 10:36:56 +0200 Subject: [M3devel] Modula-3 questions In-Reply-To: References: <20120418221024.27330@gmx.com> Message-ID: <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> Maybe of interest to original poster - Modula-3 development tools are extremely lightweight and compact. Easy to create and maintain any project, be it small or not. And portable to extreme. On Apr 19, 2012, at 1:13 AM, Coleburn, Randy wrote: > As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." This is new one to me, but - in the best Modula-3 tradition - it will be reused a lot :). > > WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. Not least of these being concepts borrowed from C++ :) > > I'm not sure if anyone has done any recent bindings to GUI toolkits. I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Apr 19 16:10:29 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:10:29 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> References: <20120418221024.27330@gmx.com> <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> Message-ID: <4F901CD5.9050405@lcwb.coop> On 04/19/2012 03:36 AM, Dragi?a Duri? wrote: > Maybe of interest to original poster - Modula-3 development tools are extremely lightweight and compact. Easy to create and maintain any project, be it small or not. And portable to extreme. > > On Apr 19, 2012, at 1:13 AM, Coleburn, Randy wrote: > >> As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." > > This is new one to me, but - in the best Modula-3 tradition - it will be reused a lot :). > >> >> WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. > > Not least of these being concepts borrowed from C++ :) > >> >> I'm not sure if anyone has done any recent bindings to GUI toolkits. > > I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. I would be interested in this binding. From rodney_bates at lcwb.coop Thu Apr 19 16:54:06 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:54:06 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: References: <20120418221024.27330@gmx.com> Message-ID: <4F90270E.5030702@lcwb.coop> On 04/18/2012 06:13 PM, Coleburn, Randy wrote: > Marresh: > > I've programmed in a number of different languages. > > For me, I've found that Modula-3 is the best for most of what I do. > > Further, I've found that the concepts in Modula-3 help you think through things in a more complete manner, thereby making you a better programmer. > > When I've been forced to use other languages, I've often found myself starting out in Modula-3 and then translating to the other language once the main concepts are defined. > > Just because Modula-3 is touted as a systems programming language doesn't mean it is too complex for simpler projects; however, if you are only wanting to write very simple, independent programs that won't ever have any parts reused anywhere else, you may find the initial discipline of interfaces and implementations a bit verbose. > > The language itself is really quite compact, given its power, and the concepts are straightforward and don't throw you curve balls. > > I can't really comment much about Oberon as I haven't used it much. > > As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." > I don't really believe this, for several reasons. C++ does add some things that make it harder. For example, you can use library (library is not language, BTW) versions of arrays, at the usual costs of heap-allocation, sometimes unnecessary. But it only works if you use it. If you do an array-bounds thing, you can blow your leg off just as badly in C as in C++. C++ preserves C's broken half-treatment of arrays, with the same possibilities for these bugs. Meanwhile, C++ adds a lot of additional ways to shoot yourself in the foot. For example, the user-defined overloading system means you can add a function declaration and have existing calls silently switch from whatever function they used to call to your new one. Or the reverse. Deleting a declaration could result in existing calls on it silently switching to some other function, instead of giving compile errors, as you would expect. A nightmare if the code is anything but small. > WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. > > I'm not sure if anyone has done any recent bindings to GUI toolkits. > > Hope this helps. > > --Randy Coleburn > > > -----Original Message----- > From: penn43 at gmx.com [mailto:penn43 at gmx.com] > Sent: Wednesday, April 18, 2012 6:10 PM > To: m3devel at elegosoft.com > Subject: [M3devel] Modula-3 questions > > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some doubts. > > The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? > > Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. > So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? > > Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). > From rodney_bates at lcwb.coop Thu Apr 19 17:02:27 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 10:02:27 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120419002550.798361A205B@async.async.caltech.edu> References: <20120418221024.27330@gmx.com> <20120419002550.798361A205B@async.async.caltech.edu> Message-ID: <4F902903.8060807@lcwb.coop> On 04/18/2012 07:25 PM, Mika Nystrom wrote: > penn43 at gmx.com writes: > ... >> P.S. is the creation and maintenance of module interfaces all that trouble? I >> read somewhere that it is a pain, and that the inconvenience of it would only >> be paid off when one has to manage large projects (which is not my case). > > I personally find the Modula-3 interface design to be one of the best > parts of the language. It would maybe be nice if it had more levels of > qualification, like Java, but that's a minor issue. The way that it's > almost impossible to get name clashes is a much bigger advantage. The Java levels-of-qualification system is not at all what it looks like at first glance. Semantically, it's no more than a flat space, with names of things allowed to have dots in them (and no doubt white space and comments around the dots.) A.B has no more relation to A.C than Shooby_Do_Bop has to HeyDownHoDownDerryDerryDown. Yeah, I know it does reflect where the source files are located in your directory structure, but aside from having no semantic significance, that's only a cultural convention. The language explicitly permits implementors to search for source files otherwise. > > And you find that the small effort required to type your procedure > prototypes pays off rather quickly... > > Finally, I could ask you what kind of programming you intend to do that > you are certain won't eventually turn into large projects :-) > > Mika > From rodney_bates at lcwb.coop Thu Apr 19 16:45:53 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:45:53 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: <4F902521.8000105@lcwb.coop> On 04/18/2012 05:10 PM, penn43 at gmx.com wrote: > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some doubts. > > The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? > C++ is 6 times more complicated than Modula-3, by reference manual page count, which is usually a reasonable, simple way to estimate complexity. Java is 8 times, though its reference manual is significantly less dense than most. Ada is 10 times. With room for some minor quibbles, Modula-3 has more useful programming features than any of these, thus the best "economy of concept", or ratio of real power to complexity. Java is especially low on this scale, since it is quite feeble, yet has an enormous reference manual. Particularly, all array- and record-like constructs are forcibly heap allocated whether you need it or not, with resulting coding overhead. You always have to allocate and either constantly NIL-check or create an argument in your head/comments that they are always non-NIL. This is usually scattered around your code. Unnecessary heap-allocation has execution space and time overhead too, but this would probably not be of concern to you. Modula-3 is also particularly good at minimizing interactions among language features. This makes it easier to learn/use a subset of the language, with less risk of tripping over something you haven't studied. That happens a _lot_ in C++ and Ada. If you ever eventually want to use more features, they are there, without having to relearn the superficial syntax, etc., of the basic stuff. > Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. > So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? > If you prefer absolute minimal language complexity without regard for programming richness, as opposed to economy of concept, the Oberon family fares better by that criterion. But I think, even with your minimal goals, you will like some of the additional things Modula-3 has. > Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). > > From dabenavidesd at yahoo.es Thu Apr 19 18:30:36 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 17:30:36 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <4F902521.8000105@lcwb.coop> Message-ID: <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I think is a good comparison to say C++ is to Java what Modula-3 is to Oberon. The typing model is similarly relatively augmented from one to the other and UNSAFE features are allowed in the former without control over it (where is in Modula-3 is more confined to UNSAFE MODULEs). Also a machine independent code is not so in the object-code sense (though Modula-3 has its own scripting extension engine). Modula-3 OBJECT TYPEs are relative number ordered but other Record-Oriented languages may have a rather distinct type classification system. C++ just makes the multiple-inheritance support system a big headache for every programmer accustomed to handle single-inheritance languages, but not counter wise case In easy of use Modula-3 hands its own distinct picture of program in terms of Modules (which handle software re usability stronger than just Object-type systems). Object Oberon instead focuses on that counter-idea. C++ is a lot like Java in the Class-word sense, which is hard to deal with when you don't have explicit INTERFACE TYPEs like Modula-3 ones (you can create object from OBJECTs their selves and INTERFACES TYPEs), Java still makes an emulation via interfaces but are not just for abstract classes, and not all kind of classes (if you don't program in that way), and you sort to adhere to that or leave it. Modula-3 modularity is more uniform from that. C++ has the template mechanism but it isn't that well designated to be a GENERIC TYPE but some sort of template of code of untyped code. This can be powerful if you want to have polymorphism but you can have a hard type figuring out what kind of template class you want in any case. This is a Modula-3 advantage since most of the type system developed after them are really oriented towards controlling that complexity via Compile-type checking (which still can make the case for a Extended-Type Checker concept) Thanks in advance --- El jue, 19/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 09:45 > > > On 04/18/2012 05:10 PM, penn43 at gmx.com > wrote: > > Dear Modula-3 developers, > > > > I am not a Modula-3 user, but I am considering becoming > one. I have already had a look at the language, and it > certainly looks interesting. However, I still have some > misgivings about starting learning Modula-3, since it would > be a considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > > I hope you can help me clarify some points and dispel > some doubts. > > > > The first point is that I would neither be working on > large projects, nor doing systems programming. I understand > these were the two major strengths of Modula-3, but neither > would be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > > > C++ is 6 times more complicated than Modula-3, by reference > manual page count, which is > usually a reasonable, simple way to estimate > complexity. Java is 8 times, though its > reference manual is significantly less dense than > most. Ada is 10 times. With room > for some minor quibbles, Modula-3 has more useful > programming features than any of these, > thus the best "economy of concept", or ratio of real power > to complexity. > > Java is especially low on this scale, since it is quite > feeble, yet has an enormous > reference manual. Particularly, all array- and > record-like constructs are forcibly heap > allocated whether you need it or not, with resulting coding > overhead. You always have > to allocate and either constantly NIL-check or create an > argument in your head/comments > that they are always non-NIL. This is usually > scattered around your code. Unnecessary > heap-allocation has execution space and time overhead too, > but this would probably not > be of concern to you. > > Modula-3 is also particularly good at minimizing > interactions among language features. > This makes it easier to learn/use a subset of the language, > with less risk of tripping > over something you haven't studied. That happens a > _lot_ in C++ and Ada. If you ever > eventually want to use more features, they are there, > without having to relearn the > superficial syntax, etc., of the basic stuff. > > > Secondly, could you please help me understand what are > the reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > > So, again, keeping in mind that I don't need the > advanced features mentioned above, nor multithreading, does > it make any sense for me to choose Modula-3 instead of > Oberon, or Object Pascal? > > > > If you prefer absolute minimal language complexity without > regard for programming richness, > as opposed to economy of concept, the Oberon family fares > better by that criterion. But I > think, even with your minimal goals, you will like some of > the additional things Modula-3 has. > > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > > > I thank you in advance. > > > > Best regards, > > > > Marresh > > > > P.S. is the creation and maintenance of module > interfaces all that trouble? I read somewhere that it is a > pain, and that the inconvenience of it would only be paid > off when one has to manage large projects (which is not my > case). > > > > > From microcode at zoho.com Thu Apr 19 18:51:29 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Thu, 19 Apr 2012 16:51:29 +0000 Subject: [M3devel] Fw: Modula-3 questions Message-ID: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> I sent this to Alejandro by mistake. It should have gone to the list. Sorry guys. -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. -----Original Message----- From: "Daniel Alejandro Benavides D." Date: Thu, 19 Apr 2012 17:30:36 To: ; Rodney M. Bates Subject: Re: [M3devel] Modula-3 questions Hi all: I think is a good comparison to say C++ is to Java what Modula-3 is to Oberon. The typing model is similarly relatively augmented from one to the other and UNSAFE features are allowed in the former without control over it (where is in Modula-3 is more confined to UNSAFE MODULEs). Also a machine independent code is not so in the object-code sense (though Modula-3 has its own scripting extension engine). Modula-3 OBJECT TYPEs are relative number ordered but other Record-Oriented languages may have a rather distinct type classification system. C++ just makes the multiple-inheritance support system a big headache for every programmer accustomed to handle single-inheritance languages, but not counter wise case In easy of use Modula-3 hands its own distinct picture of program in terms of Modules (which handle software re usability stronger than just Object-type systems). Object Oberon instead focuses on that counter-idea. C++ is a lot like Java in the Class-word sense, which is hard to deal with when you don't have explicit INTERFACE TYPEs like Modula-3 ones (you can create object from OBJECTs their selves and INTERFACES TYPEs), Java still makes an emulation via interfaces but are not just for abstract classes, and not all kind of classes (if you don't program in that way), and you sort to adhere to that or leave it. Modula-3 modularity is more uniform from that. C++ has the template mechanism but it isn't that well designated to be a GENERIC TYPE but some sort of template of code of untyped code. This can be powerful if you want to have polymorphism but you can have a hard type figuring out what kind of template class you want in any case. This is a Modula-3 advantage since most of the type system developed after them are really oriented towards controlling that complexity via Compile-type checking (which still can make the case for a Extended-Type Checker concept) Thanks in advance --- El jue, 19/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 09:45 > > > On 04/18/2012 05:10 PM, penn43 at gmx.com > wrote: > > Dear Modula-3 developers, > > > > I am not a Modula-3 user, but I am considering becoming > one. I have already had a look at the language, and it > certainly looks interesting. However, I still have some > misgivings about starting learning Modula-3, since it would > be a considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > > I hope you can help me clarify some points and dispel > some doubts. > > > > The first point is that I would neither be working on > large projects, nor doing systems programming. I understand > these were the two major strengths of Modula-3, but neither > would be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > > > C++ is 6 times more complicated than Modula-3, by reference > manual page count, which is > usually a reasonable, simple way to estimate > complexity. Java is 8 times, though its > reference manual is significantly less dense than > most. Ada is 10 times. With room > for some minor quibbles, Modula-3 has more useful > programming features than any of these, > thus the best "economy of concept", or ratio of real power > to complexity. > > Java is especially low on this scale, since it is quite > feeble, yet has an enormous > reference manual. Particularly, all array- and > record-like constructs are forcibly heap > allocated whether you need it or not, with resulting coding > overhead. You always have > to allocate and either constantly NIL-check or create an > argument in your head/comments > that they are always non-NIL. This is usually > scattered around your code. Unnecessary > heap-allocation has execution space and time overhead too, > but this would probably not > be of concern to you. > > Modula-3 is also particularly good at minimizing > interactions among language features. > This makes it easier to learn/use a subset of the language, > with less risk of tripping > over something you haven't studied. That happens a > _lot_ in C++ and Ada. If you ever > eventually want to use more features, they are there, > without having to relearn the > superficial syntax, etc., of the basic stuff. > > > Secondly, could you please help me understand what are > the reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > > So, again, keeping in mind that I don't need the > advanced features mentioned above, nor multithreading, does > it make any sense for me to choose Modula-3 instead of > Oberon, or Object Pascal? > > > > If you prefer absolute minimal language complexity without > regard for programming richness, > as opposed to economy of concept, the Oberon family fares > better by that criterion. But I > think, even with your minimal goals, you will like some of > the additional things Modula-3 has. > > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > > > I thank you in advance. > > > > Best regards, > > > > Marresh > > > > P.S. is the creation and maintenance of module > interfaces all that trouble? I read somewhere that it is a > pain, and that the inconvenience of it would only be paid > off when one has to manage large projects (which is not my > case). > > > > > From mika at async.caltech.edu Thu Apr 19 19:29:18 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 19 Apr 2012 10:29:18 -0700 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> References: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> Message-ID: <20120419172918.A32A91A205B@async.async.caltech.edu> But at the same time the Green Book (G. Nelson, ed., Systems Programming with Modula-3, Prentice-Hall 1991) is probably the best description of how to actually use object-oriented programming in practice that's ever been published... I once wrote to whoever now owns Prentice-Hall and asked their copyright clearance person for permission to photocopy chapters of that book for a class I was teaching. No response, not even "absolutely not." But most of it (all of it??) is available online. I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that if the hordes discover it, they will ruin it. One LONGINT is enough headaches for me. I find the unchanging nature of the language to be a huge advantage in what I do. Mika -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. From dknoto at next.com.pl Thu Apr 19 19:38:45 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Thu, 19 Apr 2012 19:38:45 +0200 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419172918.A32A91A205B@async.async.caltech.edu> References: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> <20120419172918.A32A91A205B@async.async.caltech.edu> Message-ID: <20120419193845.7206cc1e@wenus.next.com.pl> Dnia 2012-04-19, o godz. 10:29:18 Mika Nystrom napisa?(a): > > But at the same time the Green Book (G. Nelson, ed., Systems Programming > with Modula-3, Prentice-Hall 1991) is probably the best description of > how to actually use object-oriented programming in practice that's ever > been published... > It is a pity that Amazon does not send used books outside the U.S., the seller on eBay too. Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Thu Apr 19 20:00:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 19:00:25 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419172918.A32A91A205B@async.async.caltech.edu> Message-ID: <1334858425.89359.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: In terms of literature I believe by the long lapsus of history that has gone after that book, you don't need to understand much of it to notice that some people don't realize the language as of tremendous historic value, aided by negligent community outside. BTW Python it's one of the few that recognize its strong influence over it. But talking about history and then what happened, this matcvhes with what we are seeing: "Conferences, on how to program Object Oriented Programming"; my goodness, this is the Modula-3 history, what else are they looking for? Thanks in advance --- El jue, 19/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: microcode at zoho.com > CC: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 12:29 > > But at the same time the Green Book (G. Nelson, ed., Systems > Programming > with Modula-3, Prentice-Hall 1991) is probably the best > description of > how to actually use object-oriented programming in practice > that's ever > been published... > > I once wrote to whoever now owns Prentice-Hall and asked > their copyright > clearance person for permission to photocopy chapters of > that book > for a class I was teaching. No response, not even > "absolutely not." > But most of it (all of it??) is available online. > > I'm somewhat ambivalent about marketing Modula-3 too > hard. I fear that > if the hordes discover it, they will ruin it. One > LONGINT is enough > headaches for me. I find the unchanging nature of the > language to be > a huge advantage in what I do. > > Mika > > -----Original Message----- > From: microcode at zoho.com > Date: Thu, 19 Apr 2012 16:49:57 > To: Daniel Alejandro Benavides D. > Reply-To: microcode at zoho.com > Subject: Re: [M3devel] Modula-3 questions > > A big inhibitor to Modula-3 is the lack of books and > tutorials. CM3 has a great system running on tons of > platforms. But where can people learn to code Modula-3? > > I see this as the biggest obstacle. > > > From dabenavidesd at yahoo.es Thu Apr 19 21:20:54 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 20:20:54 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419193845.7206cc1e@wenus.next.com.pl> Message-ID: <1334863254.51331.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: In my native country (Colombia/South America) there isn't problem about redistributing copyrighted material provided that it is not for profit purposes. Or having acquirement rule in EU countries, (though the aftermath of Trading agreements might overcome that as well) might facilitate photocopies or microfilm distribution. In any case it will need some sort of Modula-3 foundation or something to validate the use of that material I guess. I like the idea of having it to use over Internet for instance in Amazon, etc, but I guess lobbying would be required. Having said that, DEC-SRC building in Palo Alto is being occupied by Amazon research Division according to Wikipedia: http://en.wikipedia.org/wiki/DEC_Systems_Research_Center I didn't make it to California, but I'm certain that we should go and ask over there. Thanks in advance --- El jue, 19/4/12, Dariusz Knoci?ski escribi?: > De: Dariusz Knoci?ski > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: m3devel at elegosoft.com, "Mika Nystrom" > Fecha: jueves, 19 de abril, 2012 12:38 > Dnia 2012-04-19, o godz. 10:29:18 > Mika Nystrom > napisa?(a): > > > > > But at the same time the Green Book (G. Nelson, ed., > Systems Programming > > with Modula-3, Prentice-Hall 1991) is probably the best > description of > > how to actually use object-oriented programming in > practice that's ever > > been published... > > > > It is a pity that Amazon does not send used books outside > the U.S., the seller > on eBay too. > > Best regards > Dariusz Knoci?ski. > From hendrik at topoi.pooq.com Fri Apr 20 04:32:39 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 19 Apr 2012 22:32:39 -0400 Subject: [M3devel] Modula-3 questions In-Reply-To: <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <4F902521.8000105@lcwb.coop> <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <20120420023238.GE5407@topoi.pooq.com> On Thu, Apr 19, 2012 at 05:30:36PM +0100, Daniel Alejandro Benavides D. wrote: > > Modula-3 modularity is more uniform from that. The nice thing about Module 3's modularity is that it's completely independent of procedures, object types, global variables, and all that. You can use the language the way you want to, and still be able to wrap up whatever kind of module makes sense for your application. -- hendrik From microcode at zoho.com Fri Apr 20 11:12:22 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Fri, 20 Apr 2012 09:12:22 +0000 Subject: [M3devel] Fw: Modula-3 questions Message-ID: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> I haven't found that book or any Modula-3 books online. I agree that things are often best left alone and often ruined by constant change and people who want to make things into other things they were never intended to be. I said something similar a few debates ago. I don't care what's popular as long as it still exists :-) ------Original Message------ From: Mika Nystrom To: microcode at zoho.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Fw: Modula-3 questions Sent: 19 Apr 2012 17:29 But at the same time the Green Book (G. Nelson, ed., Systems Programming with Modula-3, Prentice-Hall 1991) is probably the best description of how to actually use object-oriented programming in practice that's ever been published... I once wrote to whoever now owns Prentice-Hall and asked their copyright clearance person for permission to photocopy chapters of that book for a class I was teaching. No response, not even "absolutely not." But most of it (all of it??) is available online. I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that if the hordes discover it, they will ruin it. One LONGINT is enough headaches for me. I find the unchanging nature of the language to be a huge advantage in what I do. Mika -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. From rodney_bates at lcwb.coop Fri Apr 20 15:48:46 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 20 Apr 2012 08:48:46 -0500 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> References: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> Message-ID: <4F91693E.9000903@lcwb.coop> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: > I haven't found that book or any Modula-3 books online. > > I agree that things are often best left alone and often ruined by constant change and people who want to make things into other things they were never intended to be. I said something similar a few debates ago. I don't care what's popular as long as it still exists :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^ "As long as it still exists" is the critical connection to popularity here. It takes a certain minimum of interested people to keep it in existence. Despite being dramatically simpler than the alternatives, Modula-3 is still big enough that it needs several people to support it. We are really a bit low on this front. I can't seem to do the Modula-3 support I would like to do *and* use the language for my own projects too. And I'm retired. Frustrating. > > > > ------Original Message------ > From: Mika Nystrom > To: microcode at zoho.com > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Modula-3 questions > Sent: 19 Apr 2012 17:29 > > > But at the same time the Green Book (G. Nelson, ed., Systems Programming > with Modula-3, Prentice-Hall 1991) is probably the best description of > how to actually use object-oriented programming in practice that's ever > been published... > > I once wrote to whoever now owns Prentice-Hall and asked their copyright > clearance person for permission to photocopy chapters of that book > for a class I was teaching. No response, not even "absolutely not." > But most of it (all of it??) is available online. > > I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that > if the hordes discover it, they will ruin it. One LONGINT is enough > headaches for me. I find the unchanging nature of the language to be > a huge advantage in what I do. > > Mika > > -----Original Message----- > From: microcode at zoho.com > Date: Thu, 19 Apr 2012 16:49:57 > To: Daniel Alejandro Benavides D. > Reply-To: microcode at zoho.com > Subject: Re: [M3devel] Modula-3 questions > > A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? > > I see this as the biggest obstacle. > > > > From dabenavidesd at yahoo.es Fri Apr 20 16:13:06 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 15:13:06 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> Message-ID: <1334931186.57202.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Well in terms of popularity we could stand for Modula-3 in search engines and see how much we got and how much we got from other for instance say Java. It might be that there are a number of good results in Modula-3, so I don't know much effort to do countability of that. But this is just to state preeminence. Later the popularity the number of times it has been searched that word (not so recent results for google were not bad at all). Whether the community is alive and kicking I would ask another question to elucidate that clearly; if industry has a better and strong feeling for Java and C++, than for Modula-3, and computers are becoming because of the non-turning point of 40 years of crisis almost a dead end where as any new computer comes becomes substantially slower, then, I would say that would live in that Universe of industrial-strength systems are not alive by those languages, but of very "dead" languages (say Modula-3 'died' in 2000 but not talking about communities, just languages), so some good inspiration came from older days and make that industry still making some money. Concerning about community is just one or two people apart from the industrial-strength systems is certainly better since it reflects the likely it would be survived by someone, and I happen to believe that languages in **critical** times are lead by just one or maybe two people, the rest are just followers. We might create a Modula-3 facebook or social network account and quickly realize that there are dozens of people interested and get their hands dirty in this crisis no more but in a good "dead" language, if somebody says that then the language is still alive in those followers I believe so. Thanks in advance --- El vie, 20/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: viernes, 20 de abril, 2012 08:48 > > > On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > > I haven't found that book or any Modula-3 books > online. > > > > I agree that things are often best left alone and often > ruined by constant change and people who > want to make things into other things they were never > intended to be. I said something similar a few > debates ago. I don't care what's popular > as long as it still exists :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > "As long as it still exists" is the critical connection to > popularity here. It takes a certain minimum > of interested people to keep it in existence. Despite > being dramatically simpler than the alternatives, > Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this > front. > > I can't seem to do the Modula-3 support I would like to do > *and* use the language for my own projects > too. And I'm retired. Frustrating. > > > > > > > > > > > ------Original Message------ > > From: Mika Nystrom > > To: microcode at zoho.com > > Cc: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: Modula-3 questions > > Sent: 19 Apr 2012 17:29 > > > > > > But at the same time the Green Book (G. Nelson, ed., > Systems Programming > > with Modula-3, Prentice-Hall 1991) is probably the best > description of > > how to actually use object-oriented programming in > practice that's ever > > been published... > > > > I once wrote to whoever now owns Prentice-Hall and > asked their copyright > > clearance person for permission to photocopy chapters > of that book > > for a class I was teaching. No response, not even > "absolutely not." > > But most of it (all of it??) is available online. > > > > I'm somewhat ambivalent about marketing Modula-3 too > hard. I fear that > > if the hordes discover it, they will ruin it. One > LONGINT is enough > > headaches for me. I find the unchanging nature of > the language to be > > a huge advantage in what I do. > > > > Mika > > > > -----Original Message----- > > From: microcode at zoho.com > > Date: Thu, 19 Apr 2012 16:49:57 > > To: Daniel Alejandro Benavides D. > > Reply-To: microcode at zoho.com > > Subject: Re: [M3devel] Modula-3 questions > > > > A big inhibitor to Modula-3 is the lack of books and > tutorials. CM3 has a great system running on tons of > platforms. But where can people learn to code Modula-3? > > > > I see this as the biggest obstacle. > > > > > > > > > From microcode at zoho.com Fri Apr 20 17:12:43 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Fri, 20 Apr 2012 15:12:43 +0000 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> Message-ID: <20120420160023.925D3DE925@mx0.elegosoft.com> On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > On 04/20/2012 04:12 AM, microcode at zoho.com wrote: >> I haven't found that book or any Modula-3 books online. >> >> I agree that things are often best left alone and often ruined by >> constant change and people who want to make things into other things >> they were never intended to be. I said something similar a few debates >> ago. I don't care what's popular as long as it still exists :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^ > "As long as it still exists" is the critical connection to popularity > here. It takes a certain minimum of interested people to keep it in > existence. Despite being dramatically simpler than the alternatives, > Modula-3 is still big enough that it needs several people to support it. > We are really a bit low on this front. I don't know what's involved but I don't think I can be much help with coding, unfortunately. I have offered to help out with systems support in the past and the offer still stands. I can host a couple of development systems for Solaris 10 SPARC and Intel on an as-requested basis if developers need them to keep CM3 going. I believe those platforms are already supported so I don't think I'm helping much here either but just in case. > I can't seem to do the Modula-3 support I would like to do *and* use the > language for my own projects too. And I'm retired. Frustrating. Sounds like good problems to have. I will try to install CM3 on Solaris in the next few weeks. I had it on Linux but my install didn't seem like it was working since most of the examples got errors trying to build. I'm also busy with work and home stuff blah blah blah. I have a lot of things going on and I don't get to most of what I would like to either. I feel your pain ;-) From dabenavidesd at yahoo.es Fri Apr 20 18:06:38 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 17:06:38 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420023238.GE5407@topoi.pooq.com> Message-ID: <1334937998.62462.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: Interesting point but in original Modula [1], it was not that INTERFACE MODULEs were independent of, but monitors by them selves, and you could implement as you say, but later assumptions of that machines were not concurrent leave this concurrency out of the INTERFACEs. I believe that further developing that idea deserved more research than it's now, the concept of Objects as concurrent message sender receivers. Interestingly this the point of focus now on DDJ: http://www.drdobbs.com/parallel/232602463?cid=DDJ_nl_upd_2012-03-13_h&elq=be9ea13b9a534650b9e132e93de1931e The fact that the true roots of Modula's were in Mainframe machines if so, and before Object roots is appealing, o the idea is not original from them, though Some languages had featured Objects and messages before Small-talk way. So those machines were Module-oriented rather Object-oriented as some thought that is the leading architecture of new parallel systems [2] (p. 3). Thanks in advance [1] S. A. Williams, Programming models for parallel systems. J. Wiley, 1990. [2] R. Y. Kain, Computer architecture: software and hardware. Prentice Hall, 1989. --- El jue, 19/4/12, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 21:32 > On Thu, Apr 19, 2012 at 05:30:36PM > +0100, Daniel Alejandro Benavides D. wrote: > > > > Modula-3 modularity is more uniform from that. > > The nice thing about Module 3's modularity is that it's > completely > independent of procedures, object types, global variables, > and all that. > You can use the language the way you want to, and still be > able to wrap > up whatever kind of module makes sense for your > application. > > -- hendrik > From penn43 at gmx.com Fri Apr 20 21:24:24 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:24:24 +0200 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> References: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> <4F91693E.9000903@lcwb.coop> Message-ID: <20120420192424.27360@gmx.com> Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many language users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who need to maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh -------------- next part -------------- An HTML attachment was scrubbed... URL: From penn43 at gmx.com Fri Apr 20 21:30:25 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:30:25 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120420193025.27360@gmx.com> Sorry for double posting. I have just realized that my previous email was not visible (at least on Thunderbird), so I am posting it again here below. Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many Modula-3 users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who need to maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh From penn43 at gmx.com Fri Apr 20 21:37:17 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:37:17 +0200 Subject: [M3devel] Downsides of Modula-3 ? Message-ID: <20120420193717.27360@gmx.com> An object appraisal must take into account the problems too. So I am asking you, could you please mention any downsides of using Modula-3, in your experience? Of course, the non-existent language community has already been mentioned as a major downside. And the lack of documentation. What about other issues, such as compiler efficiency? Or interaction with foreign libraries? Thanks Marresh From penn43 at gmx.com Fri Apr 20 21:40:17 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:40:17 +0200 Subject: [M3devel] Downsides of Modula-3 ? Message-ID: <20120420194017.27360@gmx.com> > An object appraisal must take into account the problems too. So I am asking you, > could you please mention any downsides of using Modula-3, in your experience? Sorry, I meant to write "An objectIVE appraisal must..." From penn43 at gmx.com Fri Apr 20 21:45:08 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:45:08 +0200 Subject: [M3devel] Gtk2 binding Message-ID: <20120420194508.27350@gmx.com> > I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. Please, Dragi?a, could you share the binding with us? Thanks From dragisha at m3w.org Fri Apr 20 21:59:24 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 21:59:24 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <9553735C-579A-4564-BA89-66A42DEFE9E5@m3w.org> I don't see lack of documentation. On the contrary. Downside is - you are lone wolf. I am using a lot of foreign libraries and with C libs - no big problems. Last I used is/was libevent, and I made pretty complete OO binding around :). Efficiency of compiler, as well as ease of use is top notch. dd On Apr 20, 2012, at 9:37 PM, penn43 at gmx.com wrote: > An object appraisal must take into account the problems too. So I am asking you, could you please mention any downsides of using Modula-3, in your experience? > > Of course, the non-existent language community has already been mentioned as a major downside. > And the lack of documentation. > What about other issues, such as compiler efficiency? Or interaction with foreign libraries? > > Thanks > > Marresh From dragisha at m3w.org Fri Apr 20 22:00:33 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 22:00:33 +0200 Subject: [M3devel] Gtk2 binding In-Reply-To: <20120420194508.27350@gmx.com> References: <20120420194508.27350@gmx.com> Message-ID: <692013F4-7D06-497F-AD5C-0BA4EDCB3D62@m3w.org> If Rodney survives exposure :), I'll put a bit of effort into it and release it to public. dd On Apr 20, 2012, at 9:45 PM, penn43 at gmx.com wrote: > >> I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. > > Please, Dragi?a, could you share the binding with us? > Thanks > From mika at async.caltech.edu Fri Apr 20 22:14:37 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 13:14:37 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420193025.27360@gmx.com> References: <20120420193025.27360@gmx.com> Message-ID: <20120420201437.5C6BB1A205B@async.async.caltech.edu> penn43 at gmx.com writes: ... > >BTW How many Modula-3 users are there? This info can serve as a "reality check >", to establish whether the language is dying or not. >Also, are there newcomers to the language? Or the only programmers who use it >are those who need to maintain legacy code? Most crucially, are any NEW progra >ms written in the language? >These are crucial questions to assess the situation in a more objective way. W >hat are your views on these points? > >To start with, could you hint to what kind of projects (new/legacy code) you u >se Modula-3 for? Would you use Modula-3 if you had to start writing the same p >rograms from scratch? > >Thanks > > >Marresh > Whenever I have the choice I write new code in Modula-3 or some system built on top of it. The main projects I've done recently have been a Verilog test bench generator written in Scheme (run on top of M3); an analysis program for financial forecasting (using some "serious" matrix math, e.g., Singular Value Decomposition); a circuit timing verifier written in a combination of Modula-3 and Scheme, incorporating everything from efficient parsers (in-place parsing using recursive descent) to a simple calculus and interval arithmetic package (in Scheme); a high-frequency stock trading program (data-to-order latencies around 50 microseconds). Most of these projects would have been much more laborious with any other tool I know of, or would have involved some serious performance tradeoffs. Mika From schlepptop at henning-thielemann.de Fri Apr 20 22:14:19 2012 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 20 Apr 2012 22:14:19 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <4F91C39B.8020307@henning-thielemann.de> penn43 at gmx.com schrieb: > What about other issues, such as compiler efficiency? Or interaction with foreign libraries? INLINE across module boundaries would be nice. From dragisha at m3w.org Fri Apr 20 22:28:25 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 22:28:25 +0200 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420201437.5C6BB1A205B@async.async.caltech.edu> References: <20120420193025.27360@gmx.com> <20120420201437.5C6BB1A205B@async.async.caltech.edu> Message-ID: <448D516D-FA8F-4D7F-8078-8198BC2A1B21@m3w.org> Same here. Lone wolf aspect :). With enough luck, you write Modula-3 all the time. On Apr 20, 2012, at 10:14 PM, Mika Nystrom wrote: > Whenever I have the choice I write new code in Modula-3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Apr 20 22:29:46 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 13:29:46 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <20120420202946.0B35F1A205B@async.async.caltech.edu> Now that I have the rather unpleasant task of writing C code for a client, I have a few things I "like" about C and that I "miss" somewhat when I write Modula-3. I find that I sort of like the C preprocessor. But maybe it's just the sort of code I'm writing with it... (test programs, which need lots and lots of annotations and instrumentation, something easy to do with cpp). No alloca.... No varargs... No real "const" (Java "final"). Sometimes WITH can do it. No GO TO.............. can't believe I just wrote that but Modula-3 had as one of its design objectives to be a good target for code generation, and having goto would make that easier! (Look at the C-Mix partial evaluator for an application.) A C++ programmer would undoubtedly miss a lot of crazy C++ stuff that lets you do tricky stuff entirely without heap allocation. And operator overloading. Then there are some annoying implementation limitations: No EXTENDED floating point in the standard implementation. Bugs in the "standard" threading library (pthreads based). Have to use the longjmp hack version. Dubious "enhancements" relative to the Green Book: LONGINT, WIDECHAR (and a lot of issues with TEXT as a result). And efficiency problems in the CM3 code in *some cases* (compared with the older SRC M3). ---- My own evaluation of the above is that the things lacking relative to C are really pretty minor and the language is so much easier to use and better engineered that you almost never say to yourself "oh I wish I could write this procedure in C" (you might say it of one line of code). The implementation issues are things that could "easily" be fixed by someone who had the time.. Oh regarding efficiency problems: I still find that CM3 with optimization turned on produces code that runs faster and with a far smaller memory footprint than code doing the same thing in Java, most of the time. That's when you try to do as close to an apples-to-apples comparison as possible. If you take into account the fact that in Modula-3 you can allocate structured memory in "batches" (called "arrays"!) the difference is even bigger. Modula-3 also links far easier with C and Fortran than Java does. Mika penn43 at gmx.com writes: >An object appraisal must take into account the problems too. So I am asking yo >u, could you please mention any downsides of using Modula-3, in your experienc >e? > >Of course, the non-existent language community has already been mentioned as a > major downside. >And the lack of documentation. >What about other issues, such as compiler efficiency? Or interaction with fore >ign libraries? > >Thanks > >Marresh From penn43 at gmx.com Fri Apr 20 23:00:29 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 23:00:29 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120420210029.27340@gmx.com> > Same here. Lone wolf aspect Does the "lone wolf aspect" involve a lot of head-beating against the wall? Being a largely unsupported language, one may as well expect a lot of frustration. Honestly, how bad can it get? Any particularly problematic areas? Sorry if these nagging questions seem to you out of place. I am just trying to understand what I am getting into, if I decide to adopt Modula-3... Any real life experience greatly appreciated. From mika at async.caltech.edu Fri Apr 20 23:06:39 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 14:06:39 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420210029.27340@gmx.com> References: <20120420210029.27340@gmx.com> Message-ID: <20120420210639.D3F5A1A205B@async.async.caltech.edu> penn43 at gmx.com writes: >> Same here. Lone wolf aspect > >Does the "lone wolf aspect" involve a lot of head-beating against the wall? >Being a largely unsupported language, one may as well expect a lot of frustrat >ion. Honestly, how bad can it get? Any particularly problematic areas? People on this mailing list are very helpful, actually. Sometimes (see my previous email) the projects are a bit too big to tackle and those get left as restrictions. Serious user problems tend to happen with installation and if you care about some of the special things I mentioned in the last email. You generally don't need help with syntax (it's a simple language!) And if you want to learn "good style" I can highly recommend the Green Book's examples and some of the other libm3 code. If you need help with syntax it's generally with quake (the m3makefile language), not Modula-3 itself. In my experience this tends to happen when you want to do clever things with generics. Mika > >Sorry if these nagging questions seem to you out of place. I am just trying to > understand what I am getting into, if I decide to adopt Modula-3... Any real >life experience greatly appreciated. > From dabenavidesd at yahoo.es Fri Apr 20 23:30:31 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 22:30:31 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120420192424.27360@gmx.com> Message-ID: <1334957431.79315.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: The question it's nor complete because if there are a dozen of programmers doing something that quicks on dead languages we don't know (the larger the space the easier you can't expect an answer ), but the Universe of alive programmers in the language is easier to respond. My objective view of this is that, English speakers should like Modula-3 for processing language matters, because that's the point of a language speaker to understand and process linguistically any language written in it for post process and the only one I know that mathematically adheres to its constructs (and not even Scala nor Java are perfectly sound) is but with some sort of verification capabilities is Modula-3. I arrive at this point after hearing a comment that shows the difference technically of C++ and Modula-3 and said "Modula-3 is created for being able to prove its constructs, which C++ it by itself is not". This? technologies resort to very expressive systems, which is what Modula-3 is about You can look at SRI - PARC for Pegasys project under direction by Mark Moriconi. Thanks in advance --- El vie, 20/4/12, penn43 at gmx.com escribi?: De: penn43 at gmx.com Asunto: Re: [M3devel] Fw: Modula-3 questions Para: m3devel at elegosoft.com Fecha: viernes, 20 de abril, 2012 14:24 Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many language users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who?need to?maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views?on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Sat Apr 21 00:09:32 2012 From: mark at wickensonline.co.uk (Mark Wickens) Date: Fri, 20 Apr 2012 23:09:32 +0100 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <20120420160023.925D3DE925@mx0.elegosoft.com> References: <20120420160023.925D3DE925@mx0.elegosoft.com> Message-ID: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Hi guys, I've been following this conversation with interest. I'd like to offer my opinion, although I'm not sure I'm qualified that much to offer one. So please humour me ;) I've been a contract and permanent software engineer for over a decade now. Although it is said that you should learn a new language every year, I'm guessing the definition of the word 'learn' depends on the amount of time and intellectual power you can apply. In my case, and I'm not sure I can completely use this as an excuse, I have small children so the amount of time I've got to do anything is limited. I recognise there are limitations to any language, and Java has quite a few. Some say it has become the COBOL of the modern age. From my perspective, whilst there may be limitations, when I have a generic software problem to solve (and always in a hurry) it's very difficult to justify invest the time and effort to explore alternatives. Having said that, during Retrochallenge I've managed to code in both C, Pascal and VAX Macro (VAX/VMS languages). I did plan to spend a month coding Modula-3. This is still on the cards for a future competition. I find it very difficult to categorise programming languages in terms of interest. Clearly languages like C, C++, Java, .NET etc. with their commercial heritage are taught at University to provide students with a foot through the door to finding their first job. I ought to qualify that I'm thinking here of general purpose languages rather than domain-specific languages, such as PHP. Other languages such as Scala and Erlang are designed to try and progress the ease with which multi-process/thread applications can be developed. Other more domain-specific languages such as Ruby are attempting to solve web-centric problems... Interestingly I searched for 'programming languages hot' in google and one of the languages listed in the Infoworld article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 was COBOL, but this is primarily listed because of commercial interests. Searching job adverts for programming languages definitely won't get you the full picture. So then we have languages for academic or personal interest. So where do we think that Modula-3 fits into this picture? One thing is for sure, it's not considered a 'hot' language, so I don't think you'll find many Universities teaching it now we're into 2010+ (please, please correct me if I'm wrong). To a certain extent the participants on this list are skewed - I would imagine you could work on the Modula-3 compiler given enough architecture knowledge without necessarily having a huge amount of Modula-3 development experience. So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? Then there are people who have developed projects in Modula-3 and found it a nice/useful/productive language to develop with. Having invested time in the language it would make sense to use the language. So an alternative way of promoting the language would be to publish applications on the internet. I haven't searched for this, but I suspect that there aren't many recent articles. I have lots of other thoughts about the matter, but would welcome comments... Regards, Mark. Sent from my iPad On 20 Apr 2012, at 16:12, microcode at zoho.com wrote: > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > >> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: >>> I haven't found that book or any Modula-3 books online. >>> >>> I agree that things are often best left alone and often ruined by >>> constant change and people who want to make things into other things >>> they were never intended to be. I said something similar a few debates >>> ago. I don't care what's popular as long as it still exists :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> "As long as it still exists" is the critical connection to popularity >> here. It takes a certain minimum of interested people to keep it in >> existence. Despite being dramatically simpler than the alternatives, >> Modula-3 is still big enough that it needs several people to support it. >> We are really a bit low on this front. > > I don't know what's involved but I don't think I can be much help with > coding, unfortunately. I have offered to help out with systems support in > the past and the offer still stands. I can host a couple of development > systems for Solaris 10 SPARC and Intel on an as-requested basis if > developers need them to keep CM3 going. I believe those platforms are > already supported so I don't think I'm helping much here either but just in > case. > > >> I can't seem to do the Modula-3 support I would like to do *and* use the >> language for my own projects too. And I'm retired. Frustrating. > > Sounds like good problems to have. I will try to install CM3 on Solaris in > the next few weeks. I had it on Linux but my install didn't seem like it > was working since most of the examples got errors trying to build. I'm also > busy with work and home stuff blah blah blah. I have a lot of things going > on and I don't get to most of what I would like to either. I feel your > pain ;-) > > > From dabenavidesd at yahoo.es Sat Apr 21 01:41:49 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 00:41:49 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <1334965309.33491.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: nice idea, but it didn't work earlier, what should I work on something that anybody can do by their-selves, one of the most interesting things of learning a new language environment, is that to certain degree you are a baby in that world if you dare, that's how I feel about Modula-3, I cannot guarantee that because as Greg Nelson said, "Modula-3 definition will perpetually incomplete" and computationally he was right but depending on the tool used for doing that affirmation. Thanks in advance PS Now, imagine if they dare to define a model of software based on any language, but just if it were Modula-3 or any "real" language, the rest is just the same thing over and over again, projects that never deserve any mention. --- El vie, 20/4/12, Mark Wickens escribi?: > De: Mark Wickens > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" > Fecha: viernes, 20 de abril, 2012 17:09 > Hi guys, > > I've been following this conversation with interest. I'd > like to offer my opinion, although I'm not sure I'm > qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for > over a decade now. Although it is said that you should learn > a new language every year, I'm guessing the definition of > the word 'learn' depends on the amount of time and > intellectual power you can apply. In my case, and I'm not > sure I can completely use this as an excuse, I have small > children so the amount of time I've got to do anything is > limited. > > I recognise there are limitations to any language, and Java > has quite a few. Some say it has become the COBOL of the > modern age. From my perspective, whilst there may be > limitations, when I have a generic software problem to solve > (and always in a hurry) it's very difficult to justify > invest the time and effort to explore alternatives. Having > said that, during Retrochallenge I've managed to code in > both C, Pascal and VAX Macro (VAX/VMS languages). I did plan > to spend a month coding Modula-3. This is still on the cards > for a future competition. > > I find it very difficult to categorise programming languages > in terms of interest. Clearly languages like C, C++, Java, > .NET etc. with their commercial heritage are taught at > University to provide students with a foot through the door > to finding their first job. I ought to qualify that I'm > thinking here of general purpose languages rather than > domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try > and progress the ease with which multi-process/thread > applications can be developed. Other more domain-specific > languages such as Ruby are attempting to solve web-centric > problems... > > Interestingly I searched for 'programming languages hot' in > google and one of the languages listed in the Infoworld > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > was COBOL, but this is primarily listed because of > commercial interests. Searching job adverts for programming > languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. > So where do we think that Modula-3 fits into this picture? > One thing is for sure, it's not considered a 'hot' language, > so I don't think you'll find many Universities teaching it > now we're into 2010+ (please, please correct me if I'm > wrong). > > To a certain extent the participants on this list are skewed > - I would imagine you could work on the Modula-3 compiler > given enough architecture knowledge without necessarily > having a huge amount of Modula-3 development experience. So > could development on the compiler be sold as a way of > gaining concrete skills in compiler development (IIRC it's > all developed in C)? > > Then there are people who have developed projects in > Modula-3 and found it a nice/useful/productive language to > develop with. Having invested time in the language it would > make sense to use the language. > > So an alternative way of promoting the language would be to > publish applications on the internet. > I haven't searched for this, but I suspect that there aren't > many recent articles. > > I have lots of other thoughts about the matter, but would > welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com > wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > >>> I haven't found that book or any Modula-3 books > online. > >>> > >>> I agree that things are often best left alone > and often ruined by > >>> constant change and people who want to make > things into other things > >>> they were never intended to be. I said > something similar a few debates > >>> ago. I don't care what's popular as long as it > still exists :-) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical > connection to popularity > >> here. It takes a certain minimum of > interested people to keep it in > >> existence. Despite being dramatically simpler > than the alternatives, > >> Modula-3 is still big enough that it needs several > people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be > much help with > > coding, unfortunately. I have offered to help out with > systems support in > > the past and the offer still stands. I can host a > couple of development > > systems for Solaris 10 SPARC and Intel on an > as-requested basis if > > developers need them to keep CM3 going. I believe those > platforms are > > already supported so I don't think I'm helping much > here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would > like to do *and* use the > >> language for my own projects too. And I'm > retired. Frustrating. > > > > Sounds like good problems to have. I will try to > install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install > didn't seem like it > > was working since most of the examples got errors > trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a > lot of things going > > on and I don't get to most of what I would like to > either. I feel your > > pain ;-) > > > > > > > From dabenavidesd at yahoo.es Sat Apr 21 03:30:42 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 02:30:42 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <1334965309.33491.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <1334971842.99402.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: the last phrase taken from here: http://books.google.com.co/books?id=M3F-lhug50cC&lpg=PP1&pg=PA137#v=onepage&q&f=false and before that [1] (I clarify further real-world languages doesn't include neither Oberon or its relative cousin Java, nor Smalltalk, so this is easier to proof literally) [1] I. A. and E. S. Society, COMPASS ?94: proceedings of the Ninth Annual Conference on Computer Assurance?: June 27-July 1, 1994, National Institute of Standards and Technology, Gaithersburg, MD?: safety, reliability, fault tolerance, concurrency and real time security. Institute of Electrical and Electronics Engineers, 1994. --- El vie, 20/4/12, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" , "Mark Wickens" > Fecha: viernes, 20 de abril, 2012 18:41 > Hi all: > nice idea, but it didn't work earlier, what should I work on > something that anybody can do by their-selves, one of > the most interesting things of learning a new language > environment, is that to certain degree you are a baby in > that world if you dare, that's how I feel about Modula-3, I > cannot guarantee that because as Greg Nelson said, "Modula-3 > definition will perpetually incomplete" and computationally > he was right but depending on the tool used for doing that > affirmation. > Thanks in advance > > PS Now, imagine if they dare to define a model of software > based on any language, but just if it were Modula-3 or any > "real" language, the rest is just the same thing over and > over again, projects that never deserve any mention. > > --- El vie, 20/4/12, Mark Wickens > escribi?: > > > De: Mark Wickens > > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 > questions > > Para: "m3devel at elegosoft.com" > > > Fecha: viernes, 20 de abril, 2012 17:09 > > Hi guys, > > > > I've been following this conversation with interest. > I'd > > like to offer my opinion, although I'm not sure I'm > > qualified that much to offer one. So please humour me > ;) > > > > I've been a contract and permanent software engineer > for > > over a decade now. Although it is said that you should > learn > > a new language every year, I'm guessing the definition > of > > the word 'learn' depends on the amount of time and > > intellectual power you can apply. In my case, and I'm > not > > sure I can completely use this as an excuse, I have > small > > children so the amount of time I've got to do anything > is > > limited. > > > > I recognise there are limitations to any language, and > Java > > has quite a few. Some say it has become the COBOL of > the > > modern age. From my perspective, whilst there may be > > limitations, when I have a generic software problem to > solve > > (and always in a hurry) it's very difficult to justify > > invest the time and effort to explore alternatives. > Having > > said that, during Retrochallenge I've managed to code > in > > both C, Pascal and VAX Macro (VAX/VMS languages). I did > plan > > to spend a month coding Modula-3. This is still on the > cards > > for a future competition. > > > > I find it very difficult to categorise programming > languages > > in terms of interest. Clearly languages like C, C++, > Java, > > .NET etc. with their commercial heritage are taught at > > University to provide students with a foot through the > door > > to finding their first job. I ought to qualify that > I'm > > thinking here of general purpose languages rather than > > domain-specific languages, such as PHP. > > > > Other languages such as Scala and Erlang are designed > to try > > and progress the ease with which multi-process/thread > > applications can be developed. Other more > domain-specific > > languages such as Ruby are attempting to solve > web-centric > > problems... > > > > Interestingly I searched for 'programming languages > hot' in > > google and one of the languages listed in the > Infoworld > > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > > was COBOL, but this is primarily listed because of > > commercial interests. Searching job adverts for > programming > > languages definitely won't get you the full picture. > > > > So then we have languages for academic or personal > interest. > > So where do we think that Modula-3 fits into this > picture? > > One thing is for sure, it's not considered a 'hot' > language, > > so I don't think you'll find many Universities teaching > it > > now we're into 2010+ (please, please correct me if I'm > > wrong). > > > > To a certain extent the participants on this list are > skewed > > - I would imagine you could work on the Modula-3 > compiler > > given enough architecture knowledge without > necessarily > > having a huge amount of Modula-3 development > experience. So > > could development on the compiler be sold as a way of > > gaining concrete skills in compiler development (IIRC > it's > > all developed in C)? > > > > Then there are people who have developed projects in > > Modula-3 and found it a nice/useful/productive language > to > > develop with. Having invested time in the language it > would > > make sense to use the language. > > > > So an alternative way of promoting the language would > be to > > publish applications on the internet. > > I haven't searched for this, but I suspect that there > aren't > > many recent articles. > > > > I have lots of other thoughts about the matter, but > would > > welcome comments... > > > > Regards, Mark. > > > > Sent from my iPad > > > > On 20 Apr 2012, at 16:12, microcode at zoho.com > > wrote: > > > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > > wrote > > > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > > wrote: > > >>> I haven't found that book or any Modula-3 > books > > online. > > >>> > > >>> I agree that things are often best left > alone > > and often ruined by > > >>> constant change and people who want to > make > > things into other things > > >>> they were never intended to be. I said > > something similar a few debates > > >>> ago. I don't care what's popular as long > as it > > still exists :-) > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > >> "As long as it still exists" is the critical > > connection to popularity > > >> here. It takes a certain minimum of > > interested people to keep it in > > >> existence. Despite being dramatically > simpler > > than the alternatives, > > >> Modula-3 is still big enough that it needs > several > > people to support it. > > >> We are really a bit low on this front. > > > > > > I don't know what's involved but I don't think I > can be > > much help with > > > coding, unfortunately. I have offered to help out > with > > systems support in > > > the past and the offer still stands. I can host a > > couple of development > > > systems for Solaris 10 SPARC and Intel on an > > as-requested basis if > > > developers need them to keep CM3 going. I believe > those > > platforms are > > > already supported so I don't think I'm helping > much > > here either but just in > > > case. > > > > > > > > >> I can't seem to do the Modula-3 support I > would > > like to do *and* use the > > >> language for my own projects too. And > I'm > > retired. Frustrating. > > > > > > Sounds like good problems to have. I will try to > > install CM3 on Solaris in > > > the next few weeks. I had it on Linux but my > install > > didn't seem like it > > > was working since most of the examples got errors > > trying to build. I'm also > > > busy with work and home stuff blah blah blah. I > have a > > lot of things going > > > on and I don't get to most of what I would like > to > > either. I feel your > > > pain ;-) > > > > > > > > > > > > From jay.krell at cornell.edu Sat Apr 21 05:33:01 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Apr 2012 03:33:01 +0000 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> References: <20120420160023.925D3DE925@mx0.elegosoft.com>, <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: > So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? This merits correction: The compile is largely written in Modula-3. It is broken up into a "builder", front end, other parts, and backends. The NT/x86 backend is written in Modula-3 and outputs .obj files directly. The "builder", front end, middle stuff, cross-module checking stuff (something related to "linking", depending on your point of view), NT/x86 backend are all linked into one executable -- cm3. The other backend is gcc. When using it cm3 outputs an intermediate form, that the gcc thing reads back in. The rest is written in Modula-3. - Jay > From: mark at wickensonline.co.uk > Date: Fri, 20 Apr 2012 23:09:32 +0100 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > > Hi guys, > > I've been following this conversation with interest. I'd like to offer my opinion, although I'm not sure I'm qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for over a decade now. Although it is said that you should learn a new language every year, I'm guessing the definition of the word 'learn' depends on the amount of time and intellectual power you can apply. In my case, and I'm not sure I can completely use this as an excuse, I have small children so the amount of time I've got to do anything is limited. > > I recognise there are limitations to any language, and Java has quite a few. Some say it has become the COBOL of the modern age. From my perspective, whilst there may be limitations, when I have a generic software problem to solve (and always in a hurry) it's very difficult to justify invest the time and effort to explore alternatives. Having said that, during Retrochallenge I've managed to code in both C, Pascal and VAX Macro (VAX/VMS languages). I did plan to spend a month coding Modula-3. This is still on the cards for a future competition. > > I find it very difficult to categorise programming languages in terms of interest. Clearly languages like C, C++, Java, .NET etc. with their commercial heritage are taught at University to provide students with a foot through the door to finding their first job. I ought to qualify that I'm thinking here of general purpose languages rather than domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try and progress the ease with which multi-process/thread applications can be developed. Other more domain-specific languages such as Ruby are attempting to solve web-centric problems... > > Interestingly I searched for 'programming languages hot' in google and one of the languages listed in the Infoworld article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 was COBOL, but this is primarily listed because of commercial interests. Searching job adverts for programming languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. So where do we think that Modula-3 fits into this picture? One thing is for sure, it's not considered a 'hot' language, so I don't think you'll find many Universities teaching it now we're into 2010+ (please, please correct me if I'm wrong). > > To a certain extent the participants on this list are skewed - I would imagine you could work on the Modula-3 compiler given enough architecture knowledge without necessarily having a huge amount of Modula-3 development experience. So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? > > Then there are people who have developed projects in Modula-3 and found it a nice/useful/productive language to develop with. Having invested time in the language it would make sense to use the language. > > So an alternative way of promoting the language would be to publish applications on the internet. > I haven't searched for this, but I suspect that there aren't many recent articles. > > I have lots of other thoughts about the matter, but would welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: > >>> I haven't found that book or any Modula-3 books online. > >>> > >>> I agree that things are often best left alone and often ruined by > >>> constant change and people who want to make things into other things > >>> they were never intended to be. I said something similar a few debates > >>> ago. I don't care what's popular as long as it still exists :-) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical connection to popularity > >> here. It takes a certain minimum of interested people to keep it in > >> existence. Despite being dramatically simpler than the alternatives, > >> Modula-3 is still big enough that it needs several people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be much help with > > coding, unfortunately. I have offered to help out with systems support in > > the past and the offer still stands. I can host a couple of development > > systems for Solaris 10 SPARC and Intel on an as-requested basis if > > developers need them to keep CM3 going. I believe those platforms are > > already supported so I don't think I'm helping much here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would like to do *and* use the > >> language for my own projects too. And I'm retired. Frustrating. > > > > Sounds like good problems to have. I will try to install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install didn't seem like it > > was working since most of the examples got errors trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a lot of things going > > on and I don't get to most of what I would like to either. I feel your > > pain ;-) > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Sat Apr 21 08:43:22 2012 From: mark at wickensonline.co.uk (Mark Wickens) Date: Sat, 21 Apr 2012 07:43:22 +0100 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: References: <20120420160023.925D3DE925@mx0.elegosoft.com>, <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <4F92570A.6090302@wickensonline.co.uk> On 21/04/12 04:33, Jay K wrote: > > So could development on the compiler be sold as a way of gaining > concrete skills in compiler development (IIRC it's all developed in C)? > > This merits correction: > The compile is largely written in Modula-3. > It is broken up into a "builder", front end, other parts, and backends. > The NT/x86 backend is written in Modula-3 and outputs .obj files > directly. > The "builder", front end, middle stuff, cross-module checking stuff > (something related to "linking", depending on your point of > view), NT/x86 backend are all linked into one executable -- cm3. > The other backend is gcc. When using it cm3 outputs an intermediate > form, that the gcc thing reads back in. > The rest is written in Modula-3. > Hi Jay, Thanks for the clarification. Having sent the email I did start to wonder whether I was correct in my statement... it's been a while since I looked at Modula-3! On an operational note I got a 'Certificate Not Trusted' error when attempting to access the roadmap https://projects.elego.de/cm3/roadmap. Regards, Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Apr 21 15:40:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 14:40:04 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <1335015604.28434.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi Mark: if I'm not correct there please forgive but it is a possible answer to that picture you are trying to diagnose (specially maybe you can correct since you have known the VAX-RISC style machines of VAX9000 series if so), but I dare to believe that they put on those machines besides of VMS and Ultrix some sort of a Modula-3 OS because that was the only possible side for installing and running such a beasts smoothly. DEC abandoned the high needs application market because of marketing failures and misunderstandings (such as Parallelizing Fortran Compiler), but they have sold their right to market its super computer architecture designs to MasPar, and other computers are still supported in emulation companies and run in "Windows". Thanks in advance --- El vie, 20/4/12, Mark Wickens escribi?: > De: Mark Wickens > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" > Fecha: viernes, 20 de abril, 2012 17:09 > Hi guys, > > I've been following this conversation with interest. I'd > like to offer my opinion, although I'm not sure I'm > qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for > over a decade now. Although it is said that you should learn > a new language every year, I'm guessing the definition of > the word 'learn' depends on the amount of time and > intellectual power you can apply. In my case, and I'm not > sure I can completely use this as an excuse, I have small > children so the amount of time I've got to do anything is > limited. > > I recognise there are limitations to any language, and Java > has quite a few. Some say it has become the COBOL of the > modern age. From my perspective, whilst there may be > limitations, when I have a generic software problem to solve > (and always in a hurry) it's very difficult to justify > invest the time and effort to explore alternatives. Having > said that, during Retrochallenge I've managed to code in > both C, Pascal and VAX Macro (VAX/VMS languages). I did plan > to spend a month coding Modula-3. This is still on the cards > for a future competition. > > I find it very difficult to categorise programming languages > in terms of interest. Clearly languages like C, C++, Java, > .NET etc. with their commercial heritage are taught at > University to provide students with a foot through the door > to finding their first job. I ought to qualify that I'm > thinking here of general purpose languages rather than > domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try > and progress the ease with which multi-process/thread > applications can be developed. Other more domain-specific > languages such as Ruby are attempting to solve web-centric > problems... > > Interestingly I searched for 'programming languages hot' in > google and one of the languages listed in the Infoworld > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > was COBOL, but this is primarily listed because of > commercial interests. Searching job adverts for programming > languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. > So where do we think that Modula-3 fits into this picture? > One thing is for sure, it's not considered a 'hot' language, > so I don't think you'll find many Universities teaching it > now we're into 2010+ (please, please correct me if I'm > wrong). > > To a certain extent the participants on this list are skewed > - I would imagine you could work on the Modula-3 compiler > given enough architecture knowledge without necessarily > having a huge amount of Modula-3 development experience. So > could development on the compiler be sold as a way of > gaining concrete skills in compiler development (IIRC it's > all developed in C)? > > Then there are people who have developed projects in > Modula-3 and found it a nice/useful/productive language to > develop with. Having invested time in the language it would > make sense to use the language. > > So an alternative way of promoting the language would be to > publish applications on the internet. > I haven't searched for this, but I suspect that there aren't > many recent articles. > > I have lots of other thoughts about the matter, but would > welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com > wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > >>> I haven't found that book or any Modula-3 books > online. > >>> > >>> I agree that things are often best left alone > and often ruined by > >>> constant change and people who want to make > things into other things > >>> they were never intended to be. I said > something similar a few debates > >>> ago. I don't care what's popular as long as it > still exists :-) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical > connection to popularity > >> here. It takes a certain minimum of > interested people to keep it in > >> existence. Despite being dramatically simpler > than the alternatives, > >> Modula-3 is still big enough that it needs several > people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be > much help with > > coding, unfortunately. I have offered to help out with > systems support in > > the past and the offer still stands. I can host a > couple of development > > systems for Solaris 10 SPARC and Intel on an > as-requested basis if > > developers need them to keep CM3 going. I believe those > platforms are > > already supported so I don't think I'm helping much > here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would > like to do *and* use the > >> language for my own projects too. And I'm > retired. Frustrating. > > > > Sounds like good problems to have. I will try to > install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install > didn't seem like it > > was working since most of the examples got errors > trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a > lot of things going > > on and I don't get to most of what I would like to > either. I feel your > > pain ;-) > > > > > > > From dabenavidesd at yahoo.es Sat Apr 21 18:26:48 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 17:26:48 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420202946.0B35F1A205B@async.async.caltech.edu> Message-ID: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. Thanks in advance --- El vie, 20/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: penn43 at gmx.com > CC: m3devel at elegosoft.com > Fecha: viernes, 20 de abril, 2012 15:29 > > Now that I have the rather unpleasant task of writing C code > for a client, > I have a few things I "like" about C and that I "miss" > somewhat when > I write Modula-3. > > I find that I sort of like the C preprocessor. But > maybe it's just the > sort of code I'm writing with it... (test programs, which > need lots and > lots of annotations and instrumentation, something easy to > do with cpp). > > No alloca.... > > No varargs... > > No real "const" (Java "final"). Sometimes WITH can do > it. > > No GO TO.............. can't believe I just wrote that but > Modula-3 had > as one of its design objectives to be a good target for code > generation, > and having goto would make that easier! (Look at the > C-Mix partial > evaluator for an application.) > > A C++ programmer would undoubtedly miss a lot of crazy C++ > stuff > that lets you do tricky stuff entirely without heap > allocation. > And operator overloading. > > Then there are some annoying implementation limitations: > > No EXTENDED floating point in the standard implementation. > > Bugs in the "standard" threading library (pthreads > based). Have > to use the longjmp hack version. > > Dubious "enhancements" relative to the Green Book: LONGINT, > WIDECHAR > (and a lot of issues with TEXT as a result). And > efficiency problems > in the CM3 code in *some cases* (compared with the older SRC > M3). > > ---- > > My own evaluation of the above is that the things lacking > relative to C > are really pretty minor and the language is so much easier > to use > and better engineered that you almost never say to yourself > "oh I wish > I could write this procedure in C" (you might say it of one > line of code). > > The implementation issues are things that could "easily" be > fixed by > someone who had the time.. > > Oh regarding efficiency problems: I still find that CM3 with > optimization > turned on produces code that runs faster and with a far > smaller memory > footprint than code doing the same thing in Java, most of > the time. > That's when you try to do as close to an apples-to-apples > comparison > as possible. If you take into account the fact that in > Modula-3 you can > allocate structured memory in "batches" (called "arrays"!) > the difference > is even bigger. Modula-3 also links far easier with C > and Fortran than > Java does. > > Mika > > > > penn43 at gmx.com > writes: > >An object appraisal must take into account the problems > too. So I am asking yo > >u, could you please mention any downsides of using > Modula-3, in your experienc > >e? > > > >Of course, the non-existent language community has > already been mentioned as a > > major downside. > >And the lack of documentation. > >What about other issues, such as compiler efficiency? Or > interaction with fore > >ign libraries? > > > >Thanks > > > >Marresh > From dknoto at next.com.pl Sat Apr 21 20:26:03 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Sat, 21 Apr 2012 20:26:03 +0200 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: References: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com> <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: <20120421202603.6ed1896b@wenus.next.com.pl> Dnia 2012-02-03, o godz. 16:13:55 Jay K napisa?(a): I finally found some time on the second approach to compile CM3 from source. I have got latest source from 2012/04/13. > Darious, how about cm3 -commands -keep? These options have not tried. > This sort of error indicates either the wrong cm3cg is being run or it is > being passed the wrong file, like mixing up .ic and .io files or somesuch. > Try adding -v to the cm3cg commands. You'll have to cd to the target > directory as well (AMD64_LINUX). > > I added option "-v" to the command "./do-cm3-core.sh -v buildship" and got the following result: >>> ... === package /home/dknoto/Oprogramowanie/Modula-3/Source/m3-libs/m3core === +++ cm3 -build -DROOT='/home/dknoto/Oprogramowanie/Modula-3/Source' $RARGS && cm3 -ship $RARGS -DROOT='/home/dknoto/Oprogramowanie/Modula-3/Source' +++ EVAL ("/usr/local/cm3/bin/cm3.cfg") --- building in AMD64_LINUX --- cd AMD64_LINUX ignoring ../src/m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES inhale libm3core.m3x checking RTBuiltin.mx reading "../src/runtime/common/RTBuiltin.mx": 0 seconds checking RTHooks.i3 new source -> compiling RTHooks.i3 m3front ../src/runtime/common/RTHooks.i3 -w1 /home/dknoto/Oprogramowanie/Modula-3/Source/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks RTHooks .ic -o RTHooks.is m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. m3_backend => 1 m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic rm RTHooks.is rm RTHooks.ic rm RTHooks.is checking RTHooks.m3 checking RuntimeError.i3 checking RT0.i3 <<< In directory m3-libs/m3core/AMD64_LINUX I have not file libm3core.so.5, but I have files *.o and file libm3core.m3x. I added the full building log to the attachment. Best regards Dariusz Knoci?ski. -------------- next part -------------- A non-text attachment was scrubbed... Name: buildship-2012-04-21_19-57.log.xz Type: application/x-xz Size: 23528 bytes Desc: not available URL: From dragisha at m3w.org Sat Apr 21 23:28:15 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 21 Apr 2012 23:28:15 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: What would be LONGADDRESS? Pointer to a location inside LONGRAM? :) On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? > Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. > Thanks in advance > > --- El vie, 20/4/12, Mika Nystrom escribi?: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: penn43 at gmx.com >> CC: m3devel at elegosoft.com >> Fecha: viernes, 20 de abril, 2012 15:29 >> >> Now that I have the rather unpleasant task of writing C code >> for a client, >> I have a few things I "like" about C and that I "miss" >> somewhat when >> I write Modula-3. >> >> I find that I sort of like the C preprocessor. But >> maybe it's just the >> sort of code I'm writing with it... (test programs, which >> need lots and >> lots of annotations and instrumentation, something easy to >> do with cpp). >> >> No alloca.... >> >> No varargs... >> >> No real "const" (Java "final"). Sometimes WITH can do >> it. >> >> No GO TO.............. can't believe I just wrote that but >> Modula-3 had >> as one of its design objectives to be a good target for code >> generation, >> and having goto would make that easier! (Look at the >> C-Mix partial >> evaluator for an application.) >> >> A C++ programmer would undoubtedly miss a lot of crazy C++ >> stuff >> that lets you do tricky stuff entirely without heap >> allocation. >> And operator overloading. >> >> Then there are some annoying implementation limitations: >> >> No EXTENDED floating point in the standard implementation. >> >> Bugs in the "standard" threading library (pthreads >> based). Have >> to use the longjmp hack version. >> >> Dubious "enhancements" relative to the Green Book: LONGINT, >> WIDECHAR >> (and a lot of issues with TEXT as a result). And >> efficiency problems >> in the CM3 code in *some cases* (compared with the older SRC >> M3). >> >> ---- >> >> My own evaluation of the above is that the things lacking >> relative to C >> are really pretty minor and the language is so much easier >> to use >> and better engineered that you almost never say to yourself >> "oh I wish >> I could write this procedure in C" (you might say it of one >> line of code). >> >> The implementation issues are things that could "easily" be >> fixed by >> someone who had the time.. >> >> Oh regarding efficiency problems: I still find that CM3 with >> optimization >> turned on produces code that runs faster and with a far >> smaller memory >> footprint than code doing the same thing in Java, most of >> the time. >> That's when you try to do as close to an apples-to-apples >> comparison >> as possible. If you take into account the fact that in >> Modula-3 you can >> allocate structured memory in "batches" (called "arrays"!) >> the difference >> is even bigger. Modula-3 also links far easier with C >> and Fortran than >> Java does. >> >> Mika >> >> >> >> penn43 at gmx.com >> writes: >>> An object appraisal must take into account the problems >> too. So I am asking yo >>> u, could you please mention any downsides of using >> Modula-3, in your experienc >>> e? >>> >>> Of course, the non-existent language community has >> already been mentioned as a >>> major downside. >>> And the lack of documentation. >>> What about other issues, such as compiler efficiency? Or >> interaction with fore >>> ign libraries? >>> >>> Thanks >>> >>> Marresh >> From jay.krell at cornell.edu Sun Apr 22 01:22:37 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Apr 2012 23:22:37 +0000 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com>, Message-ID: I don't understand what LONGADDRESS is either. > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. 1) please elaborate 2) We don't use longjmp as much any more, but get/set/make/swapcontext on platforms that support them.And where we do use longjmp, we have a more portable use than before -- we no longer hack on the jmpbuf.There is a "trick" where you use sigsetstack or some such to get the stack pointer into the jmpbuf.Look at the code and read the paper referenced. It is possible it didn't work on all platforms. But anyway, see #1.We'd really prefer to just use pthreads.Hm. I'd like to look again at what pthreads features we use -- I suspect pthreads/Win32 can beabstracted more thinly and the Modula-3 code less-forked/more-shared. But later.. - Jay > From: dragisha at m3w.org > Date: Sat, 21 Apr 2012 23:28:15 +0200 > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Downsides of Modula-3 ? > > What would be LONGADDRESS? Pointer to a location inside LONGRAM? :) > > On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? > > Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. > > Thanks in advance > > > > --- El vie, 20/4/12, Mika Nystrom escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: penn43 at gmx.com > >> CC: m3devel at elegosoft.com > >> Fecha: viernes, 20 de abril, 2012 15:29 > >> > >> Now that I have the rather unpleasant task of writing C code > >> for a client, > >> I have a few things I "like" about C and that I "miss" > >> somewhat when > >> I write Modula-3. > >> > >> I find that I sort of like the C preprocessor. But > >> maybe it's just the > >> sort of code I'm writing with it... (test programs, which > >> need lots and > >> lots of annotations and instrumentation, something easy to > >> do with cpp). > >> > >> No alloca.... > >> > >> No varargs... > >> > >> No real "const" (Java "final"). Sometimes WITH can do > >> it. > >> > >> No GO TO.............. can't believe I just wrote that but > >> Modula-3 had > >> as one of its design objectives to be a good target for code > >> generation, > >> and having goto would make that easier! (Look at the > >> C-Mix partial > >> evaluator for an application.) > >> > >> A C++ programmer would undoubtedly miss a lot of crazy C++ > >> stuff > >> that lets you do tricky stuff entirely without heap > >> allocation. > >> And operator overloading. > >> > >> Then there are some annoying implementation limitations: > >> > >> No EXTENDED floating point in the standard implementation. > >> > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. > >> > >> Dubious "enhancements" relative to the Green Book: LONGINT, > >> WIDECHAR > >> (and a lot of issues with TEXT as a result). And > >> efficiency problems > >> in the CM3 code in *some cases* (compared with the older SRC > >> M3). > >> > >> ---- > >> > >> My own evaluation of the above is that the things lacking > >> relative to C > >> are really pretty minor and the language is so much easier > >> to use > >> and better engineered that you almost never say to yourself > >> "oh I wish > >> I could write this procedure in C" (you might say it of one > >> line of code). > >> > >> The implementation issues are things that could "easily" be > >> fixed by > >> someone who had the time.. > >> > >> Oh regarding efficiency problems: I still find that CM3 with > >> optimization > >> turned on produces code that runs faster and with a far > >> smaller memory > >> footprint than code doing the same thing in Java, most of > >> the time. > >> That's when you try to do as close to an apples-to-apples > >> comparison > >> as possible. If you take into account the fact that in > >> Modula-3 you can > >> allocate structured memory in "batches" (called "arrays"!) > >> the difference > >> is even bigger. Modula-3 also links far easier with C > >> and Fortran than > >> Java does. > >> > >> Mika > >> > >> > >> > >> penn43 at gmx.com > >> writes: > >>> An object appraisal must take into account the problems > >> too. So I am asking yo > >>> u, could you please mention any downsides of using > >> Modula-3, in your experienc > >>> e? > >>> > >>> Of course, the non-existent language community has > >> already been mentioned as a > >>> major downside. > >>> And the lack of documentation. > >>> What about other issues, such as compiler efficiency? Or > >> interaction with fore > >>> ign libraries? > >>> > >>> Thanks > >>> > >>> Marresh > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 22 01:36:10 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 21 Apr 2012 16:36:10 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com>, Message-ID: <20120421233610.B48281A205B@async.async.caltech.edu> Jay K writes: >1) please elaborate >2) We don't use longjmp as much any more=2C but get/set= >/make/swapcontext on platforms that support them.And where we do use longjm= >p=2C we have a more portable use than before -- we no longer hack on the jm= >pbuf.There is a "trick" where you use sigsetstack or some such to get the s= >tack pointer into the jmpbuf.Look at the code and read the paper referenced= >. It is possible it didn't work on all platforms. But anyway=2C see #1.We'= >d really prefer to just use pthreads.Hm. I'd like to look again at what pth= >reads features we use -- I suspect pthreads/Win32 can beabstracted more thi= >nly and the Modula-3 code less-forked/more-shared. But later.. - Jay > Fro= Sorry for the bad quote. My mailer still lives in the 7-bit world. In any case I was just mentioning as a problem with the current Modula-3 implementation that the pthreads bindings are buggy. I would not (and do not) use them for serious work. And user threads are, as we all know, not ideal... Anybody who wants to investigate the matter can start by running the thread testing program in m3core/tests/thread ... Main.m3 is fairly well documented. Mika From dabenavidesd at yahoo.es Sun Apr 22 18:41:28 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 17:41:28 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120421233610.B48281A205B@async.async.caltech.edu> Message-ID: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I'm more suspicious about the back needs over this programs, since Win32 programs have worked OK, have they? So I agree with you it's a matter of target implementation (not UNSAFE world), but that's in m3gcc backend, isn't it? Similarly your code could be fixed to uniprocessor semantics, so if this tests are OK either pthreads or embedded M3 threads this is a clear symptom of that UP semantics issue. In any case don't expect too many threads to do that correctly, since any exception in them can't be managed by Modula-3 RT (by language definition) but at most in m3gcc semantics I believe so. DECthreads had a nice mechanism to wrap it to Modula-3 style semantics so it could be easier to offer that in a internal CM3 API. Thanks in advance --- El s?b, 21/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Jay K" > CC: m3devel at elegosoft.com > Fecha: s?bado, 21 de abril, 2012 18:36 > Jay K writes: > >1) please elaborate > > >2) We don't use longjmp as much any more=2C but > get/set= > >/make/swapcontext on platforms that support them.And > where we do use longjm= > >p=2C we have a more portable use than before -- we no > longer hack on the jm= > >pbuf.There is a "trick" where you use sigsetstack or > some such to get the s= > >tack pointer into the jmpbuf.Look at the code and read > the paper referenced= > >. It is possible it didn't work on all platforms. > But anyway=2C see #1.We'= > >d really prefer to just use pthreads.Hm. I'd like to > look again at what pth= > >reads features we use -- I suspect pthreads/Win32 can > beabstracted more thi= > >nly and the Modula-3 code less-forked/more-shared. But > later.. - Jay > Fro= > > Sorry for the bad quote. My mailer still lives in the > 7-bit world. > > In any case I was just mentioning as a problem with the > current Modula-3 > implementation that the pthreads bindings are buggy. I > would not (and > do not) use them for serious work. And user threads > are, as we all know, > not ideal... > > Anybody who wants to investigate the matter can start by > running the thread > testing program in m3core/tests/thread ... Main.m3 is > fairly well documented. > > Mika > From dabenavidesd at yahoo.es Sun Apr 22 19:18:46 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 18:18:46 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: Message-ID: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space. Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit. Then the question what it would be like AMD64. Thanks in advance --- El s?b, 21/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com > Fecha: s?bado, 21 de abril, 2012 16:28 > What would be LONGADDRESS? Pointer to > a location inside LONGRAM? :) > > On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > If we accept to exist LONGINT and ADDRESS is a Word.T > why we don't have LONGADDRESS? That's you don't care if > that's in UNSAFE TYPE, do you? > > Assembly in lining was handled about perfect in > Modula-2 for VMS I wonder why DEC didn't provide Modula-3 > support with that as well. > > Thanks in advance > > > > --- El vie, 20/4/12, Mika Nystrom > escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: penn43 at gmx.com > >> CC: m3devel at elegosoft.com > >> Fecha: viernes, 20 de abril, 2012 15:29 > >> > >> Now that I have the rather unpleasant task of > writing C code > >> for a client, > >> I have a few things I "like" about C and that I > "miss" > >> somewhat when > >> I write Modula-3. > >> > >> I find that I sort of like the C > preprocessor. But > >> maybe it's just the > >> sort of code I'm writing with it... (test programs, > which > >> need lots and > >> lots of annotations and instrumentation, something > easy to > >> do with cpp). > >> > >> No alloca.... > >> > >> No varargs... > >> > >> No real "const" (Java "final"). Sometimes > WITH can do > >> it. > >> > >> No GO TO.............. can't believe I just wrote > that but > >> Modula-3 had > >> as one of its design objectives to be a good target > for code > >> generation, > >> and having goto would make that easier! (Look > at the > >> C-Mix partial > >> evaluator for an application.) > >> > >> A C++ programmer would undoubtedly miss a lot of > crazy C++ > >> stuff > >> that lets you do tricky stuff entirely without > heap > >> allocation. > >> And operator overloading. > >> > >> Then there are some annoying implementation > limitations: > >> > >> No EXTENDED floating point in the standard > implementation. > >> > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. > >> > >> Dubious "enhancements" relative to the Green Book: > LONGINT, > >> WIDECHAR > >> (and a lot of issues with TEXT as a result). > And > >> efficiency problems > >> in the CM3 code in *some cases* (compared with the > older SRC > >> M3). > >> > >> ---- > >> > >> My own evaluation of the above is that the things > lacking > >> relative to C > >> are really pretty minor and the language is so much > easier > >> to use > >> and better engineered that you almost never say to > yourself > >> "oh I wish > >> I could write this procedure in C" (you might say > it of one > >> line of code). > >> > >> The implementation issues are things that could > "easily" be > >> fixed by > >> someone who had the time.. > >> > >> Oh regarding efficiency problems: I still find that > CM3 with > >> optimization > >> turned on produces code that runs faster and with a > far > >> smaller memory > >> footprint than code doing the same thing in Java, > most of > >> the time. > >> That's when you try to do as close to an > apples-to-apples > >> comparison > >> as possible. If you take into account the > fact that in > >> Modula-3 you can > >> allocate structured memory in "batches" (called > "arrays"!) > >> the difference > >> is even bigger. Modula-3 also links far > easier with C > >> and Fortran than > >> Java does. > >> > >> Mika > >> > >> > >> > >> penn43 at gmx.com > >> writes: > >>> An object appraisal must take into account the > problems > >> too. So I am asking yo > >>> u, could you please mention any downsides of > using > >> Modula-3, in your experienc > >>> e? > >>> > >>> Of course, the non-existent language community > has > >> already been mentioned as a > >>> major downside. > >>> And the lack of documentation. > >>> What about other issues, such as compiler > efficiency? Or > >> interaction with fore > >>> ign libraries? > >>> > >>> Thanks > >>> > >>> Marresh > >> > > From mika at async.caltech.edu Sun Apr 22 19:30:34 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Apr 2012 10:30:34 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <20120422173034.8ED311A205B@async.async.caltech.edu> I'm almost certain the problem is somewhere in the pthreads implementation of M3 threads, which consists of a couple of files of C and M3 within m3core. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >I'm more suspicious about the back needs over this programs, since Win32 pr= >ograms have worked OK, have they? So I agree with you it's a matter of targ= >et implementation (not UNSAFE world), but that's in m3gcc backend, isn't it= >? >Similarly your code could be fixed to uniprocessor semantics, so if this te= >sts are OK either pthreads or embedded M3 threads this is a clear symptom o= >f that UP semantics issue. >In any case don't expect too many threads to do that correctly, since any e= >xception in them can't be managed by Modula-3 RT (by language definition) b= >ut at most in m3gcc semantics I believe so. DECthreads had a nice mechanism= > to wrap it to Modula-3 style semantics so it could be easier to offer that= > in a internal CM3 API. >Thanks in advance > > >--- El s=E1b, 21/4/12, Mika Nystrom escribi=F3: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Jay K" >> CC: m3devel at elegosoft.com >> Fecha: s=E1bado, 21 de abril, 2012 18:36 >> Jay K writes: >> >1) please elaborate=20 >>=20 >> >2) We don't use longjmp as much any more=3D2C but >> get/set=3D >> >/make/swapcontext on platforms that support them.And >> where we do use longjm=3D >> >p=3D2C we have a more portable use than before -- we no >> longer hack on the jm=3D >> >pbuf.There is a "trick" where you use sigsetstack or >> some such to get the s=3D >> >tack pointer into the jmpbuf.Look at the code and read >> the paper referenced=3D >> >. It is possible it didn't work on all platforms.=20 >> But anyway=3D2C see #1.We'=3D >> >d really prefer to just use pthreads.Hm. I'd like to >> look again at what pth=3D >> >reads features we use -- I suspect pthreads/Win32 can >> beabstracted more thi=3D >> >nly and the Modula-3 code less-forked/more-shared. But >> later.. - Jay > Fro=3D >>=20 >> Sorry for the bad quote. My mailer still lives in the >> 7-bit world. >>=20 >> In any case I was just mentioning as a problem with the >> current Modula-3 >> implementation that the pthreads bindings are buggy. I >> would not (and >> do not) use them for serious work. And user threads >> are, as we all know, >> not ideal... >>=20 >> Anybody who wants to investigate the matter can start by >> running the thread >> testing program in m3core/tests/thread ... Main.m3 is >> fairly well documented. >>=20 >> Mika >> From mika at async.caltech.edu Sun Apr 22 19:43:28 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Apr 2012 10:43:28 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <20120422174328.68DB81A205B@async.async.caltech.edu> But the thing is, if the produced code were thread unsafe, it likely wouldn't work with user threads either... I admit what you say is possible but it ought to be ruled out by the semantics of pthreads. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >Please this makes think that the current systems are a lottery, because the= >y don't mark thread-safe code (or they are all safe assumed as thread-unsaf= >e): >http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe > >Even if they compiler is not threaded by itself it can cause a back-end to = >be thread-unsafe, so that's why I say that it could be in that back-end. > >But then the code must be marked by each module and I think assuming all ar= >e thread-unsafe is correct to say. >Thanks in advance > >--- El dom, 22/4/12, Mika Nystrom escribi=F3: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Daniel Alejandro Benavides D." >> CC: m3devel at elegosoft.com >> Fecha: domingo, 22 de abril, 2012 12:30 >>=20 >> I'm almost certain the problem is somewhere in the pthreads >> implementation >> of M3 threads, which consists of a couple of files of C and >> M3 within >> m3core. >>=20 >> Mika >>=20 >> "Daniel Alejandro Benavides D." writes: >> >Hi all: >> >I'm more suspicious about the back needs over this >> programs, since Win32 pr=3D >> >ograms have worked OK, have they? So I agree with you >> it's a matter of targ=3D >> >et implementation (not UNSAFE world), but that's in >> m3gcc backend, isn't it=3D >> >? >> >Similarly your code could be fixed to uniprocessor >> semantics, so if this te=3D >> >sts are OK either pthreads or embedded M3 threads this >> is a clear symptom o=3D >> >f that UP semantics issue. >> >In any case don't expect too many threads to do that >> correctly, since any e=3D >> >xception in them can't be managed by Modula-3 RT (by >> language definition) b=3D >> >ut at most in m3gcc semantics I believe so. DECthreads >> had a nice mechanism=3D >> > to wrap it to Modula-3 style semantics so it could be >> easier to offer that=3D >> > in a internal CM3 API. >> >Thanks in advance >> > >> > >> >--- El s=3DE1b, 21/4/12, Mika Nystrom >> escribi=3DF3: >> > >> >> De: Mika Nystrom >> >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> >> Para: "Jay K" >> >> CC: m3devel at elegosoft.com >> >> Fecha: s=3DE1bado, 21 de abril, 2012 18:36 >> >> Jay K writes: >> >> >1) please elaborate=3D20 >> >>=3D20 >> >> >2) We don't use longjmp as much any more=3D3D2C >> but >> >> get/set=3D3D >> >> >/make/swapcontext on platforms that support >> them.And >> >> where we do use longjm=3D3D >> >> >p=3D3D2C we have a more portable use than before >> -- we no >> >> longer hack on the jm=3D3D >> >> >pbuf.There is a "trick" where you use >> sigsetstack or >> >> some such to get the s=3D3D >> >> >tack pointer into the jmpbuf.Look at the code >> and read >> >> the paper referenced=3D3D >> >> >. It is possible it didn't work on all >> platforms.=3D20 >> >> But anyway=3D3D2C see #1.We'=3D3D >> >> >d really prefer to just use pthreads.Hm. I'd >> like to >> >> look again at what pth=3D3D >> >> >reads features we use -- I suspect >> pthreads/Win32 can >> >> beabstracted more thi=3D3D >> >> >nly and the Modula-3 code >> less-forked/more-shared. But >> >> later.. - Jay > Fro=3D3D >> >>=3D20 >> >> Sorry for the bad quote. My mailer still >> lives in the >> >> 7-bit world. >> >>=3D20 >> >> In any case I was just mentioning as a problem with >> the >> >> current Modula-3 >> >> implementation that the pthreads bindings are >> buggy. I >> >> would not (and >> >> do not) use them for serious work. And user >> threads >> >> are, as we all know, >> >> not ideal... >> >>=3D20 >> >> Anybody who wants to investigate the matter can >> start by >> >> running the thread >> >> testing program in m3core/tests/thread ...=20 >> Main.m3 is >> >> fairly well documented. >> >>=3D20 >> >> Mika >> >>=20 >> From dabenavidesd at yahoo.es Sun Apr 22 19:40:31 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 18:40:31 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120422173034.8ED311A205B@async.async.caltech.edu> Message-ID: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Please this makes think that the current systems are a lottery, because they don't mark thread-safe code (or they are all safe assumed as thread-unsafe): http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe Even if they compiler is not threaded by itself it can cause a back-end to be thread-unsafe, so that's why I say that it could be in that back-end. But then the code must be marked by each module and I think assuming all are thread-unsafe is correct to say. Thanks in advance --- El dom, 22/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 12:30 > > I'm almost certain the problem is somewhere in the pthreads > implementation > of M3 threads, which consists of a couple of files of C and > M3 within > m3core. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I'm more suspicious about the back needs over this > programs, since Win32 pr= > >ograms have worked OK, have they? So I agree with you > it's a matter of targ= > >et implementation (not UNSAFE world), but that's in > m3gcc backend, isn't it= > >? > >Similarly your code could be fixed to uniprocessor > semantics, so if this te= > >sts are OK either pthreads or embedded M3 threads this > is a clear symptom o= > >f that UP semantics issue. > >In any case don't expect too many threads to do that > correctly, since any e= > >xception in them can't be managed by Modula-3 RT (by > language definition) b= > >ut at most in m3gcc semantics I believe so. DECthreads > had a nice mechanism= > > to wrap it to Modula-3 style semantics so it could be > easier to offer that= > > in a internal CM3 API. > >Thanks in advance > > > > > >--- El s=E1b, 21/4/12, Mika Nystrom > escribi=F3: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Jay K" > >> CC: m3devel at elegosoft.com > >> Fecha: s=E1bado, 21 de abril, 2012 18:36 > >> Jay K writes: > >> >1) please elaborate=20 > >>=20 > >> >2) We don't use longjmp as much any more=3D2C > but > >> get/set=3D > >> >/make/swapcontext on platforms that support > them.And > >> where we do use longjm=3D > >> >p=3D2C we have a more portable use than before > -- we no > >> longer hack on the jm=3D > >> >pbuf.There is a "trick" where you use > sigsetstack or > >> some such to get the s=3D > >> >tack pointer into the jmpbuf.Look at the code > and read > >> the paper referenced=3D > >> >. It is possible it didn't work on all > platforms.=20 > >> But anyway=3D2C see #1.We'=3D > >> >d really prefer to just use pthreads.Hm. I'd > like to > >> look again at what pth=3D > >> >reads features we use -- I suspect > pthreads/Win32 can > >> beabstracted more thi=3D > >> >nly and the Modula-3 code > less-forked/more-shared. But > >> later.. - Jay > Fro=3D > >>=20 > >> Sorry for the bad quote. My mailer still > lives in the > >> 7-bit world. > >>=20 > >> In any case I was just mentioning as a problem with > the > >> current Modula-3 > >> implementation that the pthreads bindings are > buggy. I > >> would not (and > >> do not) use them for serious work. And user > threads > >> are, as we all know, > >> not ideal... > >>=20 > >> Anybody who wants to investigate the matter can > start by > >> running the thread > >> testing program in m3core/tests/thread ... > Main.m3 is > >> fairly well documented. > >>=20 > >> Mika > >> > From dabenavidesd at yahoo.es Sun Apr 22 20:01:21 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 19:01:21 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120422174328.68DB81A205B@async.async.caltech.edu> Message-ID: <1335117681.25789.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I agree too, but then that is assuming that you code is inherently thread-safe, which we don't care either or worse in Modula-e libraries BTW, we could have THREADSAFE or SAFE keyword of that and so ... Now, what Antony and someone once said, that "embedded" green threads are not that semantically correct assuming some things over them (for instance UP semantics), then we should make some primitives for handling the new implementation of threads just to be sure. Thanks in advance --- El dom, 22/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 12:43 > > But the thing is, if the produced code were thread unsafe, > it likely > wouldn't work with user threads either... > > I admit what you say is possible but it ought to be ruled > out by the > semantics of pthreads. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >Please this makes think that the current systems are a > lottery, because the= > >y don't mark thread-safe code (or they are all safe > assumed as thread-unsaf= > >e): > >http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe > > > >Even if they compiler is not threaded by itself it can > cause a back-end to = > >be thread-unsafe, so that's why I say that it could be > in that back-end. > > > >But then the code must be marked by each module and I > think assuming all ar= > >e thread-unsafe is correct to say. > >Thanks in advance > > > >--- El dom, 22/4/12, Mika Nystrom > escribi=F3: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Daniel Alejandro Benavides D." > >> CC: m3devel at elegosoft.com > >> Fecha: domingo, 22 de abril, 2012 12:30 > >>=20 > >> I'm almost certain the problem is somewhere in the > pthreads > >> implementation > >> of M3 threads, which consists of a couple of files > of C and > >> M3 within > >> m3core. > >>=20 > >> Mika > >>=20 > >> "Daniel Alejandro Benavides D." writes: > >> >Hi all: > >> >I'm more suspicious about the back needs over > this > >> programs, since Win32 pr=3D > >> >ograms have worked OK, have they? So I agree > with you > >> it's a matter of targ=3D > >> >et implementation (not UNSAFE world), but > that's in > >> m3gcc backend, isn't it=3D > >> >? > >> >Similarly your code could be fixed to > uniprocessor > >> semantics, so if this te=3D > >> >sts are OK either pthreads or embedded M3 > threads this > >> is a clear symptom o=3D > >> >f that UP semantics issue. > >> >In any case don't expect too many threads to do > that > >> correctly, since any e=3D > >> >xception in them can't be managed by Modula-3 > RT (by > >> language definition) b=3D > >> >ut at most in m3gcc semantics I believe so. > DECthreads > >> had a nice mechanism=3D > >> > to wrap it to Modula-3 style semantics so it > could be > >> easier to offer that=3D > >> > in a internal CM3 API. > >> >Thanks in advance > >> > > >> > > >> >--- El s=3DE1b, 21/4/12, Mika Nystrom > >> escribi=3DF3: > >> > > >> >> De: Mika Nystrom > >> >> Asunto: Re: [M3devel] Downsides of > Modula-3 ? > >> >> Para: "Jay K" > >> >> CC: m3devel at elegosoft.com > >> >> Fecha: s=3DE1bado, 21 de abril, 2012 > 18:36 > >> >> Jay K writes: > >> >> >1) please elaborate=3D20 > >> >>=3D20 > >> >> >2) We don't use longjmp as much any > more=3D3D2C > >> but > >> >> get/set=3D3D > >> >> >/make/swapcontext on platforms that > support > >> them.And > >> >> where we do use longjm=3D3D > >> >> >p=3D3D2C we have a more portable use > than before > >> -- we no > >> >> longer hack on the jm=3D3D > >> >> >pbuf.There is a "trick" where you use > >> sigsetstack or > >> >> some such to get the s=3D3D > >> >> >tack pointer into the jmpbuf.Look at > the code > >> and read > >> >> the paper referenced=3D3D > >> >> >. It is possible it didn't work on > all > >> platforms.=3D20 > >> >> But anyway=3D3D2C see #1.We'=3D3D > >> >> >d really prefer to just use > pthreads.Hm. I'd > >> like to > >> >> look again at what pth=3D3D > >> >> >reads features we use -- I suspect > >> pthreads/Win32 can > >> >> beabstracted more thi=3D3D > >> >> >nly and the Modula-3 code > >> less-forked/more-shared. But > >> >> later.. - Jay > Fro=3D3D > >> >>=3D20 > >> >> Sorry for the bad quote. My mailer > still > >> lives in the > >> >> 7-bit world. > >> >>=3D20 > >> >> In any case I was just mentioning as a > problem with > >> the > >> >> current Modula-3 > >> >> implementation that the pthreads bindings > are > >> buggy. I > >> >> would not (and > >> >> do not) use them for serious work. > And user > >> threads > >> >> are, as we all know, > >> >> not ideal... > >> >>=3D20 > >> >> Anybody who wants to investigate the > matter can > >> start by > >> >> running the thread > >> >> testing program in m3core/tests/thread > ...=20 > >> Main.m3 is > >> >> fairly well documented. > >> >>=3D20 > >> >> Mika > >> >>=20 > >> > From rodney_bates at lcwb.coop Sun Apr 22 20:43:07 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Apr 2012 13:43:07 -0500 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <4F94513B.3060802@lcwb.coop> On 04/22/2012 11:41 AM, Daniel Alejandro Benavides D. wrote: > Hi all: > I'm more suspicious about the back needs over this programs, since Win32 programs have worked OK, have they? So I agree with you it's a matter of target implementation (not UNSAFE world), but that's in m3gcc backend, isn't it? > Similarly your code could be fixed to uniprocessor semantics, so if this tests are OK either pthreads or embedded M3 threads this is a clear symptom of that UP semantics issue. > In any case don't expect too many threads to do that correctly, since any exception in them can't be managed by Modula-3 RT (by language definition) I'm not sure what you mean by this, but in my reading, the language definition fully defines the interaction between threads and exceptions. Exceptions can propagate only within a thread. All the rules about where they propagate are in terms of either a statically enclosing block or a dynamic parent, that is, the caller of the current procedure. In both cases, it's strictly within the thread where the exception was raised. If an exception ever got to the top of the call chain of its thread, it would have to be the result of an override of the apply method of the closure passed to Thread.Fork. But that method has an empty RAISES clause, so if that should happen, it would be a runtime error, still within the thread. but at most in m3gcc semantics I believe so. DECthreads had a nice mechanism to wrap it to Modula-3 style semantics so it could be easier to offer that in a internal CM3 API. > Thanks in advance > > > --- El s?b, 21/4/12, Mika Nystrom escribi?: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Jay K" >> CC: m3devel at elegosoft.com >> Fecha: s?bado, 21 de abril, 2012 18:36 >> Jay K writes: >>> 1) please elaborate >> >>> 2) We don't use longjmp as much any more=2C but >> get/set= >>> /make/swapcontext on platforms that support them.And >> where we do use longjm= >>> p=2C we have a more portable use than before -- we no >> longer hack on the jm= >>> pbuf.There is a "trick" where you use sigsetstack or >> some such to get the s= >>> tack pointer into the jmpbuf.Look at the code and read >> the paper referenced= >>> . It is possible it didn't work on all platforms. >> But anyway=2C see #1.We'= >>> d really prefer to just use pthreads.Hm. I'd like to >> look again at what pth= >>> reads features we use -- I suspect pthreads/Win32 can >> beabstracted more thi= >>> nly and the Modula-3 code less-forked/more-shared. But >> later.. - Jay> Fro= >> >> Sorry for the bad quote. My mailer still lives in the >> 7-bit world. >> >> In any case I was just mentioning as a problem with the >> current Modula-3 >> implementation that the pthreads bindings are buggy. I >> would not (and >> do not) use them for serious work. And user threads >> are, as we all know, >> not ideal... >> >> Anybody who wants to investigate the matter can start by >> running the thread >> testing program in m3core/tests/thread ... Main.m3 is >> fairly well documented. >> >> Mika >> > From dragisha at m3w.org Sun Apr 22 20:50:42 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 22 Apr 2012 20:50:42 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: In other words, let's invent another non-portability :). Pass, please :) On Apr 22, 2012, at 7:18 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space. > Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit. > Then the question what it would be like AMD64. > Thanks in advance > > --- El s?b, 21/4/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Daniel Alejandro Benavides D." >> CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com >> Fecha: s?bado, 21 de abril, 2012 16:28 >> What would be LONGADDRESS? Pointer to >> a location inside LONGRAM? :) >> >> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. >> wrote: >> >>> Hi all: >>> If we accept to exist LONGINT and ADDRESS is a Word.T >> why we don't have LONGADDRESS? That's you don't care if >> that's in UNSAFE TYPE, do you? >>> Assembly in lining was handled about perfect in >> Modula-2 for VMS I wonder why DEC didn't provide Modula-3 >> support with that as well. >>> Thanks in advance >>> >>> --- El vie, 20/4/12, Mika Nystrom >> escribi?: >>> >>>> De: Mika Nystrom >>>> Asunto: Re: [M3devel] Downsides of Modula-3 ? >>>> Para: penn43 at gmx.com >>>> CC: m3devel at elegosoft.com >>>> Fecha: viernes, 20 de abril, 2012 15:29 >>>> >>>> Now that I have the rather unpleasant task of >> writing C code >>>> for a client, >>>> I have a few things I "like" about C and that I >> "miss" >>>> somewhat when >>>> I write Modula-3. >>>> >>>> I find that I sort of like the C >> preprocessor. But >>>> maybe it's just the >>>> sort of code I'm writing with it... (test programs, >> which >>>> need lots and >>>> lots of annotations and instrumentation, something >> easy to >>>> do with cpp). >>>> >>>> No alloca.... >>>> >>>> No varargs... >>>> >>>> No real "const" (Java "final"). Sometimes >> WITH can do >>>> it. >>>> >>>> No GO TO.............. can't believe I just wrote >> that but >>>> Modula-3 had >>>> as one of its design objectives to be a good target >> for code >>>> generation, >>>> and having goto would make that easier! (Look >> at the >>>> C-Mix partial >>>> evaluator for an application.) >>>> >>>> A C++ programmer would undoubtedly miss a lot of >> crazy C++ >>>> stuff >>>> that lets you do tricky stuff entirely without >> heap >>>> allocation. >>>> And operator overloading. >>>> >>>> Then there are some annoying implementation >> limitations: >>>> >>>> No EXTENDED floating point in the standard >> implementation. >>>> >>>> Bugs in the "standard" threading library (pthreads >>>> based). Have >>>> to use the longjmp hack version. >>>> >>>> Dubious "enhancements" relative to the Green Book: >> LONGINT, >>>> WIDECHAR >>>> (and a lot of issues with TEXT as a result). >> And >>>> efficiency problems >>>> in the CM3 code in *some cases* (compared with the >> older SRC >>>> M3). >>>> >>>> ---- >>>> >>>> My own evaluation of the above is that the things >> lacking >>>> relative to C >>>> are really pretty minor and the language is so much >> easier >>>> to use >>>> and better engineered that you almost never say to >> yourself >>>> "oh I wish >>>> I could write this procedure in C" (you might say >> it of one >>>> line of code). >>>> >>>> The implementation issues are things that could >> "easily" be >>>> fixed by >>>> someone who had the time.. >>>> >>>> Oh regarding efficiency problems: I still find that >> CM3 with >>>> optimization >>>> turned on produces code that runs faster and with a >> far >>>> smaller memory >>>> footprint than code doing the same thing in Java, >> most of >>>> the time. >>>> That's when you try to do as close to an >> apples-to-apples >>>> comparison >>>> as possible. If you take into account the >> fact that in >>>> Modula-3 you can >>>> allocate structured memory in "batches" (called >> "arrays"!) >>>> the difference >>>> is even bigger. Modula-3 also links far >> easier with C >>>> and Fortran than >>>> Java does. >>>> >>>> Mika >>>> >>>> >>>> >>>> penn43 at gmx.com >>>> writes: >>>>> An object appraisal must take into account the >> problems >>>> too. So I am asking yo >>>>> u, could you please mention any downsides of >> using >>>> Modula-3, in your experienc >>>>> e? >>>>> >>>>> Of course, the non-existent language community >> has >>>> already been mentioned as a >>>>> major downside. >>>>> And the lack of documentation. >>>>> What about other issues, such as compiler >> efficiency? Or >>>> interaction with fore >>>>> ign libraries? >>>>> >>>>> Thanks >>>>> >>>>> Marresh >>>> >> >> From penn43 at gmx.com Mon Apr 23 16:30:06 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Mon, 23 Apr 2012 16:30:06 +0200 Subject: [M3devel] Support for UTF-8 and email protocols Message-ID: <20120423143006.27340@gmx.com> Hi, sorry if I asked this question before, but it went unanswered and I really need to know. Are there available libraries that support: 1) UTF-8 text 2) email protocols (SMTP and POP3) -- I need client-side support ONLY. (These two functionalities are distinct, of course.) Thanks Marresh From dabenavidesd at yahoo.es Mon Apr 23 23:46:53 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Apr 2012 22:46:53 +0100 (BST) Subject: [M3devel] Support for UTF-8 and email protocols In-Reply-To: <20120423143006.27340@gmx.com> Message-ID: <1335217613.54933.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: Support of basics is there but there isn't too much in examples, etc. WIDECHAR type is the basic building block for your UTF support, but you need to be wise, somehow, it is still untested by most of us. Support for the protocol on that eagerly needs work, I don't any known free coded server system that is portable for truth, so I'd guess that unless somebody needed it, nobody has yet one client for Modula-3 or such. Instead there could be an approach but it's too much top-down using GenVoca coming from Avoca OS written in Modula-3 for writing network protocols. I hope it helps. Thanks in advance --- El lun, 23/4/12, penn43 at gmx.com escribi?: > De: penn43 at gmx.com > Asunto: [M3devel] Support for UTF-8 and email protocols > Para: m3devel at elegosoft.com > Fecha: lunes, 23 de abril, 2012 09:30 > Hi, > > sorry if I asked this question before, but it went > unanswered and I really need to know. > > Are there available libraries that support: > > 1) UTF-8 text > > 2) email protocols (SMTP and POP3) -- I need client-side > support ONLY. > > (These two functionalities are distinct, of course.) > > Thanks > > Marresh > > From dabenavidesd at yahoo.es Tue Apr 24 16:42:39 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 24 Apr 2012 15:42:39 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance --- El dom, 22/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 13:50 > In other words, let's invent another > non-portability :). > > Pass, please :) > > On Apr 22, 2012, at 7:18 PM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > I think it would be in I386 (I remember were 16 bits) > and absolute address location of a Word.T were handled as > such in I386 process at least that's in my MSJ Vol. 7 No.4, > because it has Application Address Space and at top System > Address Space. > > Similarly in ARMv7the virtual address space is 32-bit, > but physically extended to be 40-bit. > > Then the question what it would be like AMD64. > > Thanks in advance > > > > --- El s?b, 21/4/12, Dragi?a Duri? > escribi?: > > > >> De: Dragi?a Duri? > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Daniel Alejandro Benavides D." > >> CC: penn43 at gmx.com, > "Mika Nystrom" , > m3devel at elegosoft.com > >> Fecha: s?bado, 21 de abril, 2012 16:28 > >> What would be LONGADDRESS? Pointer to > >> a location inside LONGRAM? :) > >> > >> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro > Benavides D. > >> wrote: > >> > >>> Hi all: > >>> If we accept to exist LONGINT and ADDRESS is a > Word.T > >> why we don't have LONGADDRESS? That's you don't > care if > >> that's in UNSAFE TYPE, do you? > >>> Assembly in lining was handled about perfect > in > >> Modula-2 for VMS I wonder why DEC didn't provide > Modula-3 > >> support with that as well. > >>> Thanks in advance > >>> > >>> --- El vie, 20/4/12, Mika Nystrom > >> escribi?: > >>> > >>>> De: Mika Nystrom > >>>> Asunto: Re: [M3devel] Downsides of Modula-3 > ? > >>>> Para: penn43 at gmx.com > >>>> CC: m3devel at elegosoft.com > >>>> Fecha: viernes, 20 de abril, 2012 15:29 > >>>> > >>>> Now that I have the rather unpleasant task > of > >> writing C code > >>>> for a client, > >>>> I have a few things I "like" about C and > that I > >> "miss" > >>>> somewhat when > >>>> I write Modula-3. > >>>> > >>>> I find that I sort of like the C > >> preprocessor. But > >>>> maybe it's just the > >>>> sort of code I'm writing with it... (test > programs, > >> which > >>>> need lots and > >>>> lots of annotations and instrumentation, > something > >> easy to > >>>> do with cpp). > >>>> > >>>> No alloca.... > >>>> > >>>> No varargs... > >>>> > >>>> No real "const" (Java "final"). > Sometimes > >> WITH can do > >>>> it. > >>>> > >>>> No GO TO.............. can't believe I just > wrote > >> that but > >>>> Modula-3 had > >>>> as one of its design objectives to be a > good target > >> for code > >>>> generation, > >>>> and having goto would make that > easier! (Look > >> at the > >>>> C-Mix partial > >>>> evaluator for an application.) > >>>> > >>>> A C++ programmer would undoubtedly miss a > lot of > >> crazy C++ > >>>> stuff > >>>> that lets you do tricky stuff entirely > without > >> heap > >>>> allocation. > >>>> And operator overloading. > >>>> > >>>> Then there are some annoying > implementation > >> limitations: > >>>> > >>>> No EXTENDED floating point in the standard > >> implementation. > >>>> > >>>> Bugs in the "standard" threading library > (pthreads > >>>> based). Have > >>>> to use the longjmp hack version. > >>>> > >>>> Dubious "enhancements" relative to the > Green Book: > >> LONGINT, > >>>> WIDECHAR > >>>> (and a lot of issues with TEXT as a > result). > >> And > >>>> efficiency problems > >>>> in the CM3 code in *some cases* (compared > with the > >> older SRC > >>>> M3). > >>>> > >>>> ---- > >>>> > >>>> My own evaluation of the above is that the > things > >> lacking > >>>> relative to C > >>>> are really pretty minor and the language is > so much > >> easier > >>>> to use > >>>> and better engineered that you almost never > say to > >> yourself > >>>> "oh I wish > >>>> I could write this procedure in C" (you > might say > >> it of one > >>>> line of code). > >>>> > >>>> The implementation issues are things that > could > >> "easily" be > >>>> fixed by > >>>> someone who had the time.. > >>>> > >>>> Oh regarding efficiency problems: I still > find that > >> CM3 with > >>>> optimization > >>>> turned on produces code that runs faster > and with a > >> far > >>>> smaller memory > >>>> footprint than code doing the same thing in > Java, > >> most of > >>>> the time. > >>>> That's when you try to do as close to an > >> apples-to-apples > >>>> comparison > >>>> as possible. If you take into account > the > >> fact that in > >>>> Modula-3 you can > >>>> allocate structured memory in "batches" > (called > >> "arrays"!) > >>>> the difference > >>>> is even bigger. Modula-3 also links > far > >> easier with C > >>>> and Fortran than > >>>> Java does. > >>>> > >>>> Mika > >>>> > >>>> > >>>> > >>>> penn43 at gmx.com > >>>> writes: > >>>>> An object appraisal must take into > account the > >> problems > >>>> too. So I am asking yo > >>>>> u, could you please mention any > downsides of > >> using > >>>> Modula-3, in your experienc > >>>>> e? > >>>>> > >>>>> Of course, the non-existent language > community > >> has > >>>> already been mentioned as a > >>>>> major downside. > >>>>> And the lack of documentation. > >>>>> What about other issues, such as > compiler > >> efficiency? Or > >>>> interaction with fore > >>>>> ign libraries? > >>>>> > >>>>> Thanks > >>>>> > >>>>> Marresh > >>>> > >> > >> > > From dknoto at next.com.pl Tue Apr 24 20:28:05 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Tue, 24 Apr 2012 20:28:05 +0200 Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 Message-ID: <20120424202805.26f30211@wenus.next.com.pl> Hello All, I still have not resolved the problem of CM3 build from source on Fedora 16 x86_64. However, I installed Ubuntu 12.04 Beta i686 in VirtualBox and CM3 5.9.0 2012/04/13 compilation went smoothly. So I wonder how it compiles CM3 on x86_64 architecture? Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Tue Apr 24 21:18:09 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 24 Apr 2012 20:18:09 +0100 (BST) Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 In-Reply-To: <20120424202805.26f30211@wenus.next.com.pl> Message-ID: <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: I guess you are asking about how to produce a bootstrap image for cm3-min in LINUXAMD64, and the truth is that it uses the back-end for doing that but Jay knows the details. The front end doesn't know too much about about machine itself (or tries to ignore it) which makes it more portable code though not easier, so all the details might be related with m3gcc In any event, did you try the Fedora 16 package: http://pkgs.org/fedora-16/rpm-sphere-x86_64/cm3-5.8.6-11.1.x86_64.rpm.html It has a cm3 image maybe you could just scripts/do-cm3-std.sh buildship Thanks in advance --- El mar, 24/4/12, Dariusz Knoci?ski escribi?: > De: Dariusz Knoci?ski > Asunto: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > Para: m3devel at elegosoft.com > Fecha: martes, 24 de abril, 2012 13:28 > Hello All, > I still have not resolved the problem of CM3 build from > source on Fedora 16 > x86_64. However, I installed Ubuntu 12.04 Beta i686 in > VirtualBox and CM3 > 5.9.0 2012/04/13 compilation went smoothly. So I wonder how > it compiles CM3 on > x86_64 architecture? > Best regards > Dariusz Knoci?ski. > From jay.krell at cornell.edu Wed Apr 25 05:30:57 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 25 Apr 2012 03:30:57 +0000 Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 In-Reply-To: <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> References: <20120424202805.26f30211@wenus.next.com.pl>, <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: The information is buried here: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/doc/notes/porting.txt?rev=1.6;content-type=text%2Fplain - do a build of m3core, libm3, and the pieces that make up cm3, BUT stopping at the output of assembly -- not running the assembler and linker (scripts/python/boot1.py NEWTARGET) - package up (tar/gzip) the assembly files, as well as some .c files (done by boot1.py, sitting in the current working directory) - copy that to the target system (scp or ftp) - unpackage (untar/gzip) - cd step missing here - make - giving us cm3 - use that cm3 to then build the entire system on the new target missing instructions for the last step...but it is just to put cm3 in $PATH and run something in scripts...boot2.py maybe? - Jay > Date: Tue, 24 Apr 2012 20:18:09 +0100 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; dknoto at next.com.pl > Subject: Re: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > > Hi all: > I guess you are asking about how to produce a bootstrap image for cm3-min in LINUXAMD64, and the truth is that it uses the back-end for doing that but Jay knows the details. > > The front end doesn't know too much about about machine itself (or tries to ignore it) which makes it more portable code though not easier, so all the details might be related with m3gcc > > In any event, did you try the Fedora 16 package: > http://pkgs.org/fedora-16/rpm-sphere-x86_64/cm3-5.8.6-11.1.x86_64.rpm.html > > It has a cm3 image maybe you could just scripts/do-cm3-std.sh buildship > > Thanks in advance > > --- El mar, 24/4/12, Dariusz Knoci?ski escribi?: > > > De: Dariusz Knoci?ski > > Asunto: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > > Para: m3devel at elegosoft.com > > Fecha: martes, 24 de abril, 2012 13:28 > > Hello All, > > I still have not resolved the problem of CM3 build from > > source on Fedora 16 > > x86_64. However, I installed Ubuntu 12.04 Beta i686 in > > VirtualBox and CM3 > > 5.9.0 2012/04/13 compilation went smoothly. So I wonder how > > it compiles CM3 on > > x86_64 architecture? > > Best regards > > Dariusz Knoci?ski. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 25 15:08:03 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 25 Apr 2012 15:08:03 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, what can I say? > Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From dataf4l at gmail.com Wed Apr 25 18:08:28 2012 From: dataf4l at gmail.com (felipe valdez) Date: Wed, 25 Apr 2012 11:08:28 -0500 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: References: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size > per architecture. Of course there are various architectures, with their > various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you > expect one thread of your program to run on one CPU, second thread on > another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, > etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are > planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less > stressful, I mean, even the OS/400 has this feature of 128 pointers to > allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course > this would require more TYPE declarations and VAR as well (LADR, LVAR), but > could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, > what can I say? > Thanks in advance > > > -- 312-444-2124 Skype: f3l.headhunter Casa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 25 21:24:30 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 25 Apr 2012 20:24:30 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier? in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 25 23:37:43 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 25 Apr 2012 23:37:43 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <81486992-135C-4366-87A2-C126E45A7B68@m3w.org> Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor > > I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. > > Thanks in advance > > --- El mi?, 25/4/12, felipe valdez escribi?: > > De: felipe valdez > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Dragi?a Duri?" > CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 11:08 > > that is quite a response. > > > On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. >> So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. >> We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. >> >> So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. >> It must be done carefully aggressively because this is a changing world, what can I say? >> Thanks in advance > > > > > -- > 312-444-2124 > Skype: f3l.headhunter > Casa: 8043901 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 26 18:58:38 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Apr 2012 17:58:38 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <81486992-135C-4366-87A2-C126E45A7B68@m3w.org> Message-ID: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. Thank your? LONGINT? is easy just to say? LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER and LONGADDRESS<:ADDRESS so that the same function maps LONGINT ->ADDRESS Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. Thanks in advance --- El mi?, 25/4/12, Dragi?a Duri? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Daniel Alejandro Benavides D." CC: "felipe valdez" , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 16:37 Single "execution space" can span over various architectures ?in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen.? On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space.? It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier? in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Apr 26 19:44:18 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 26 Apr 2012 19:44:18 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Daniel, LONGINT and INTEGER are scalar types with no relation except one's values are subset of another. References to them are strongly typed in Modula-3 - meaning types are semantically different - but their representation is same as ADDRESS. In single address space you have all memory location addressable by same pointer type - ADDRESS. They can differ in alignment, depending on implementation decisions, but that is something else. Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied semantical informationis used where it is needed and it is not worry of language user unless she/he does something related to language environments other than Modula-3. Think RPC, OpenCL (GPU), ... On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, 8byte. Most 64bit platforms today are limited in number of address lines from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am sure it is limited to some number smaller than 64 on every 64bit platform today. But - that does not mean (Modula-3) language implementor will make PHYSADDRESS pointer type 6 bytes long. You probably can find such types in some experimental languages you are interested in. Good luck there, for/but I am not :). Unless my English-foreign is mismatched more than I think to your English-foreign, we are almost orthogonal in this discussion for some time. I checked, I am still writing to m3devel. Are you? :) dd On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. > In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. > Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER > and LONGADDRESS<:ADDRESS so that the same function maps > LONGINT ->ADDRESS > Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. > Thanks in advance > > > --- El mi?, 25/4/12, Dragi?a Duri? escribi?: > > De: Dragi?a Duri? > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Daniel Alejandro Benavides D." > CC: "felipe valdez" , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 16:37 > > Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. > > RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. > > On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. > > GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. > > It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. > > On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? >> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor >> >> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor >> >> I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. >> >> Thanks in advance >> >> --- El mi?, 25/4/12, felipe valdez escribi?: >> >> De: felipe valdez >> Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] >> Para: "Dragi?a Duri?" >> CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com >> Fecha: mi?rcoles, 25 de abril, 2012 11:08 >> >> that is quite a response. >> >> >> On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: >> As my first hands-on CPU was 6502, I think I remember a lot. >> >> ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. >> >> What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? >> >> On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. >>> So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. >>> We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. >>> >>> So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. >>> It must be done carefully aggressively because this is a changing world, what can I say? >>> Thanks in advance >> >> >> >> >> -- >> 312-444-2124 >> Skype: f3l.headhunter >> Casa: 8043901 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dataf4l at gmail.com Thu Apr 26 20:34:08 2012 From: dataf4l at gmail.com (felipe valdez) Date: Thu, 26 Apr 2012 13:34:08 -0500 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Message-ID: English, here, is the keyword. On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: > Daniel, > > LONGINT and INTEGER are scalar types with no relation except one's values > are subset of another. References to them are strongly typed in Modula-3 - > meaning types are semantically different - but their representation is same > as ADDRESS. In single address space you have all memory location > addressable by same pointer type - ADDRESS. They can differ in alignment, > depending on implementation decisions, but that is something else. > Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied > semantical informationis used where it is needed and it is not worry of > language user unless she/he does something related to language environments > other than Modula-3. Think RPC, OpenCL (GPU), ... > > On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, > 8byte. Most 64bit platforms today are limited in number of address lines > from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am > sure it is limited to some number smaller than 64 on every 64bit platform > today. But - that does not mean (Modula-3) language implementor will make > PHYSADDRESS pointer type 6 bytes long. You probably can find such types in > some experimental languages you are interested in. Good luck there, for/but > I am not :). > > Unless my English-foreign is mismatched more than I think to your > English-foreign, we are almost orthogonal in this discussion for some time. > I checked, I am still writing to m3devel. Are you? :) > > dd > > On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > In that sense, it's neither Physical or logical but process communications > are both (so hat's why its called Inter-process), but conceptually, you can > speak of that if that's what you mean. > In one of such architectures (as a Bus-oriented architecture > micro-processor) there are Logical Address (INTEGER), as the direction of a > physical processor bus ID, (where there is a one to one mapping LBID to > PBID) or a System Bus ID (ADDRESS), which identifies the location of a > kernel function. > Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because > you would want such a type of LBID address and function location, wouldn't > you? And then the location itself is and expressed by REF LONGINT<:REF > INTEGER > and LONGADDRESS<:ADDRESS so that the same function maps > LONGINT ->ADDRESS > Modula-3 type hierarchy does say that, doesn't it? This is because it is > contra variant type hierarchy. > Thanks in advance > > > --- El *mi?, 25/4/12, Dragi?a Duri? * escribi?: > > > De: Dragi?a Duri? > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Daniel Alejandro Benavides D." > CC: "felipe valdez" , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 16:37 > > Single "execution space" can span over various architectures in few ways. > Examples - RPC and GPU. > > RPC is nothing new and it does not presume multi architecture for single > object file. Nor it presumes single address space for various > components/processes. There is cross-process boundary where conversions > (data marshaling/unmarshalling) happen. > > On the other hand, GPU programming? No cross-process boundary in RPC > style, it almost looks like it is single executable - but it is not > "multiple CPU architecture per single object". Nor does it include single > address space for various object components included. > > GPU is an excellent example of what you are, very obliquely, hinting at. > But - it is not single object file for multiple architectures for single > address space. > > It is probably good idea for you to look at GPU's today to see what is > realistic in multi-architecture object generation/application. > > On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > Such as a module generating code, for sending both LONGINTs and > LONGADDRESSes through networks of wide processing units MCU (e.g array > processors)? > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor > > I guess I should tell you one, but there are too many to count examples, > in any case you would want to be truly multi platform and cross-porting > easier in general, rather than based in one base case, though Modula was > too good to make such things difficult in any case. If it serves to know > multitasking of DEC has been emulated through the AMD Bulldozer > microarchitecture with Array/Vector processor, etc. But it still needs more > cooperation (or at least using shared standards) on the industry to return > to those good days. > > Thanks in advance > > --- El *mi?, 25/4/12, felipe valdez * escribi?: > > > De: felipe valdez > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Dragi?a Duri?" > CC: "Daniel Alejandro Benavides D." , > m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 11:08 > > that is quite a response. > > > On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size > per architecture. Of course there are various architectures, with their > various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you > expect one thread of your program to run on one CPU, second thread on > another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, > etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are > planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less > stressful, I mean, even the OS/400 has this feature of 128 pointers to > allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course > this would require more TYPE declarations and VAR as well (LADR, LVAR), but > could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, > what can I say? > Thanks in advance > > > > > > -- > 312-444-2124 > Skype: f3l.headhunter > Casa: 8043901 > > > > > -- 312-444-2124 Skype: f3l.headhunter Casa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 26 20:56:59 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Apr 2012 19:56:59 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335466619.60883.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Well, I'm not so passing the fact that it is a computer more than a language what we are talking here. I was reading had several kinds of invariant type rules or covariant ones, but they found it was harder than they thought, so, I'm more type-orthogonal as such in Modula-3, the questions are more related to that than how to control language capabilities, which are very much simplified, however no many languages try to do the other part see what's in the machine. I think Dragisha's point is whether I reply myself, or just himself. So I don't care if anybody responses that's for sure, thought I won't do that my self. Thanks in advance --- El jue, 26/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: jueves, 26 de abril, 2012 13:34 English, here, is the keyword. On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: Daniel, LONGINT and INTEGER are scalar types with no relation except one's values are subset of another. References to them are strongly typed in Modula-3 - meaning types are semantically different - but their representation is same as ADDRESS. In single address space you have all memory location addressable by same pointer type - ADDRESS. They can differ in alignment, depending on implementation decisions, but that is something else. Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied semantical informationis used where it is needed and it is not worry of language user unless she/he does something related to language environments other than Modula-3. Think RPC, OpenCL (GPU), ... On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, 8byte. Most 64bit platforms today are limited in number of address lines from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am sure it is limited to some number smaller than 64 on every 64bit platform today. But - that does not mean (Modula-3) language implementor will make PHYSADDRESS pointer type 6 bytes long. You probably can find such types in some experimental languages you are interested in. Good luck there, for/but I am not :). Unless my English-foreign is mismatched more than I think to your English-foreign, we are almost orthogonal in this discussion for some time. I checked, I am still writing to m3devel. Are you? :) dd On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: Hi all: In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER and LONGADDRESS<:ADDRESS so that the same function maps LONGINT ->ADDRESS Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. Thanks in advance --- El mi?, 25/4/12, Dragi?a Duri? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Daniel Alejandro Benavides D." CC: "felipe valdez" , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 16:37 Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -- 312-444-2124Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 26 22:36:03 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 26 Apr 2012 16:36:03 -0400 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Message-ID: <20120426203603.GF4670@topoi.pooq.com> On Thu, Apr 26, 2012 at 01:34:08PM -0500, felipe valdez wrote: > English, here, is the keyword. > > > On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: > > > Daniel, > > > > On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, > > 8byte. Most 64bit platforms today are limited in number of address lines > > from CPU to memory, The rest can still be used within the processor for addressing virtual memory, which can be mapped to physical memory in a bewildering variety of ways, and can exceed physical RAM. -- hendrik From dragisha at m3w.org Thu Apr 26 23:31:02 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 26 Apr 2012 23:31:02 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <20120426203603.GF4670@topoi.pooq.com> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> <20120426203603.GF4670@topoi.pooq.com> Message-ID: <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> And still - ADDRESS type is 64bit. No 48, no 54 - but 64. As all (L|I)?LP64 pointer types are. On Apr 26, 2012, at 10:36 PM, Hendrik Boom wrote: > On Thu, Apr 26, 2012 at 01:34:08PM -0500, felipe valdez wrote: >> English, here, is the keyword. >> >> >> On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: >> >>> Daniel, >>> >>> On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, >>> 8byte. Most 64bit platforms today are limited in number of address lines >>> from CPU to memory, > > The rest can still be used within the processor for addressing virtual > memory, which can be mapped to physical memory in a bewildering variety > of ways, and can exceed physical RAM. > > -- hendrik From dabenavidesd at yahoo.es Fri Apr 27 04:50:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 27 Apr 2012 03:50:04 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <4F94513B.3060802@lcwb.coop> Message-ID: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Have you read this, if the answer is not, maybe you should, because it seems, this person knows that from the beginning there were problems in the language specification in thread semantics. https://groups.google.com/group/comp.arch/msg/880a211df40506ab?hl=en Rodney (and Mika), please make sure your code (implementation) is OK with standard semantics likewise I will do try to accept the Modula-3 semantics of threads are OK, hum, this could be fun, but, very hard, even Larch/Modula-3 might not be able to correct every error on it (so then I might say that is correct and safe, but anything SAFE). Of course there will always room running in circles but still is better to check if something else can be done properly, I mean, that you can't be safe-threaded for %100, can you? That's maybe why they drop the word SAFE for Modula-3 and that's good, they are honest. Thanks in advance --- El dom, 22/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 13:43 > > > On 04/22/2012 11:41 AM, Daniel Alejandro Benavides D. > wrote: > > Hi all: > > I'm more suspicious about the back needs over this > programs, since Win32 programs have worked OK, have they? So > I agree with you it's a matter of target implementation (not > UNSAFE world), but that's in m3gcc backend, isn't it? > > Similarly your code could be fixed to uniprocessor > semantics, so if this tests are OK either pthreads or > embedded M3 threads this is a clear symptom of that UP > semantics issue. > > In any case don't expect too many threads to do that > correctly, since any exception in them can't be managed by > Modula-3 RT > (by language definition) > > I'm not sure what you mean by this, but in my reading, the > language definition fully defines the interaction > between threads and exceptions. Exceptions can > propagate only within a thread. All the rules about > where > they propagate are in terms of either a statically enclosing > block or a dynamic parent, that is, the caller > of the current procedure. In both cases, it's strictly > within the thread where the exception was raised. > > If an exception ever got to the top of the call chain of its > thread, it would have to be the result of an > override of the apply method of the closure passed to > Thread.Fork. But that method has an empty RAISES > clause, so if that should happen, it would be a runtime > error, still within the thread. > > but at most in m3gcc semantics I believe so. DECthreads had > a nice mechanism to wrap it to Modula-3 style semantics > so it could be easier to offer that in a internal CM3 API. > > Thanks in advance > > > > > > --- El s?b, 21/4/12, Mika Nystrom > escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Jay K" > >> CC: m3devel at elegosoft.com > >> Fecha: s?bado, 21 de abril, 2012 18:36 > >> Jay K writes: > >>> 1) please elaborate > >> > >>> 2) We don't use longjmp as much any more=2C > but > >> get/set= > >>> /make/swapcontext on platforms that support > them.And > >> where we do use longjm= > >>> p=2C we have a more portable use than before -- > we no > >> longer hack on the jm= > >>> pbuf.There is a "trick" where you use > sigsetstack or > >> some such to get the s= > >>> tack pointer into the jmpbuf.Look at the code > and read > >> the paper referenced= > >>> . It is possible it didn't work on all > platforms. > >> But anyway=2C see #1.We'= > >>> d really prefer to just use pthreads.Hm. I'd > like to > >> look again at what pth= > >>> reads features we use -- I suspect > pthreads/Win32 can > >> beabstracted more thi= > >>> nly and the Modula-3 code > less-forked/more-shared. But > >> later.. - Jay> Fro= > >> > >> Sorry for the bad quote. My mailer still > lives in the > >> 7-bit world. > >> > >> In any case I was just mentioning as a problem with > the > >> current Modula-3 > >> implementation that the pthreads bindings are > buggy. I > >> would not (and > >> do not) use them for serious work. And user > threads > >> are, as we all know, > >> not ideal... > >> > >> Anybody who wants to investigate the matter can > start by > >> running the thread > >> testing program in m3core/tests/thread ... > Main.m3 is > >> fairly well documented. > >> > >> Mika > >> > > > From mika at async.caltech.edu Fri Apr 27 05:02:28 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Apr 2012 20:02:28 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: <20120427030228.B46BC1A205B@async.async.caltech.edu> "Daniel Alejandro Benavides D." writes: >Hi all: >Have you read this, if the answer is not, maybe you should, because it seem= >s, this person knows that from the beginning there were problems in the lan= >guage specification in thread semantics. >https://groups.google.com/group/comp.arch/msg/880a211df40506ab?hl=3Den > >Rodney (and Mika), please make sure your code (implementation) is OK with s= >tandard semantics likewise I will do try to accept the Modula-3 semantics o= >f threads are OK, hum, this could be fun, but, very hard, even Larch/Modula= >-3 might not be able to correct every error on it (so then I might say that= > is correct and safe, but anything SAFE). Of course there will always room = >running in circles but still is better to check if something else can be do= >ne properly, I mean, that you can't be safe-threaded for %100, can you? Tha= >t's maybe why they drop the word SAFE for Modula-3 and that's good, they ar= >e honest. >Thanks in advance I think the early specs of the Modula-3 threads were a bit loose, yes. I am pretty sure this was corrected for the formal verification. You can read about this in the Green Book, too. It is interesting that the author of the thread to which you refer essentially claims that C doesn't guarantee what one might think it claims. This would suggest that there may be things one shouldn't assume about pthreads. My Modula-3 code (in the thread tester program) is really nothing special. Please review it yourself and let me know if you find any issues. It's not particularly complicated... Mika From dragisha at m3w.org Fri Apr 27 09:41:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 09:41:29 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427030228.B46BC1A205B@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> Message-ID: <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> On Apr 27, 2012, at 5:02 AM, Mika Nystrom wrote: > > It is interesting that the author of the thread to which you refer essentially > claims that C doesn't guarantee what one might think it claims. This would suggest > that there may be things one shouldn't assume about pthreads. There is well known paper by Hans Boehm, possibly of interest to Daniel: http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html He cites Java Memory Model paper (also of possible interest here) and Boehm states problem is being addressed at moment. So, it's maybe only of historical interest now. > My Modula-3 code (in the thread tester program) is really nothing special. > Please review it yourself and let me know if you find any issues. > It's not particularly complicated? When I was implementing NPTL based threads for pm3 (around 2004) I met interesting issues with few thread programs in pm3 distribution. Those programs were written and tested with user space threads where order of thread execution was, for ready threads, always same. One was pp, as I remember... I am reading your source code just now. And one thing caught my eye: "Each type of thread starts by sleeping for a while, to give the other threads a chance to be created." Does not look like any guarantee to me, not in threaded application. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Apr 27 10:26:09 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 10:26:09 +0200 Subject: [M3devel] thread test (Mika) Message-ID: Did anyone run combinations of tests and found minimal test sets where breaks happen? I tried read,alloc and it breaks. read only does not. From small number of tests I performed, it looks like RTAllocator is real culprit here. Most breaks happens while allocating, even one I saw in FileRd.Init() while running -tests read,alloc . From dragisha at m3w.org Fri Apr 27 10:53:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 10:53:29 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: References: Message-ID: <765A576E-5D12-424A-BFFE-C06F51472A03@m3w.org> Oh, it does :). In FileRd.Init(). And during stop-the-world. IIRC, Tony mentioned allocation is solved by giving separate page to every thread to allocate new data from. It looks like straightforward method, and problem proof. But it also has border mooments where new pages are given to threads. Also a problem - world suspension from garbage collector. In less than 10 starts whole system deadlocked at least four times. On Apr 27, 2012, at 10:26 AM, Dragi?a Duri? wrote: > I tried read,alloc and it breaks. read only does not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Apr 27 19:13:40 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Apr 2012 10:13:40 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> Message-ID: <20120427171341.0D83E1A205E@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: ... >I am reading your source code just now. And one thing caught my eye: = >"Each type of thread starts by sleeping for a while, to give the other = >threads a chance to be created." Does not look like any guarantee to me, = >not in threaded application.=20= If the program prints "running" then all threads have been created. It eventually prints "running". Therefore all threads are created. --- The things wrong with CM3's pthreads threading are NOT subtle. The runtime completely freezes up, ctrl-C stops working, and other such things. Mika From dragisha at m3w.org Fri Apr 27 19:30:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 19:30:29 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427171341.0D83E1A205E@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> Message-ID: I do not doubt they are created. Probably not an issue with 3 threads here, 3 threads there, but it can be if one relies on "must be created after some arbitrary time" in any synchronization. I did, and SRC people did, at least in two places. I just don't see it as a good practice. BTW, your test is excellent stress machine. My laptops hate it, probably, till now :). Right now I am focused on an allocation race issue and I hope to fix it in few hours/a day. On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > ... >> I am reading your source code just now. And one thing caught my eye: = >> "Each type of thread starts by sleeping for a while, to give the other = >> threads a chance to be created." Does not look like any guarantee to me, = >> not in threaded application.=20= > > If the program prints "running" then all threads have been created. > > It eventually prints "running". > > Therefore all threads are created. > > --- > > The things wrong with CM3's pthreads threading are NOT subtle. > The runtime completely freezes up, ctrl-C stops working, and other > such things. > > Mika From mika at async.caltech.edu Fri Apr 27 19:49:48 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Apr 2012 10:49:48 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> Message-ID: <20120427174948.9BB191A205B@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >I do not doubt they are created. Probably not an issue with 3 threads = >here, 3 threads there, but it can be if one relies on "must be created = >after some arbitrary time" in any synchronization. I did, and SRC people = >did, at least in two places. I just don't see it as a good practice. Yes I have had that bug in my programs a few times. But to be really fair it's not that you're assuming that another thread is created by a certain time but you're assuming that it has done something by the time the first thread needs to do something else. In the examples of the sort you describe it is usually that the newly created thread has "had time to initialize" (in some way). My bug with this was of this nature: thread A: ... Thread.Fork(b)... wait... LOCK(b.mu) Thread B: ... self.mu := NEW(MUTEX) ... Oops! works on some threading implementations (user threads). Instant segfault on others! Have fun with the thread tester. It doesn't find any problems with user threads. I should probably have dug into the pthreads myself long ago but it's always so far down the todo list, and all my CM3 installations use user threads by necessity. If you can improve the pthreads I think it would make me much happier about CM3 in general. I still use PM3 as much as possible... Mika > >BTW, your test is excellent stress machine. My laptops hate it, = >probably, till now :). Right now I am focused on an allocation race = >issue and I hope to fix it in few hours/a day. > >On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: > >> =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >> ... >>> I am reading your source code just now. And one thing caught my eye: = >=3D >>> "Each type of thread starts by sleeping for a while, to give the = >other =3D >>> threads a chance to be created." Does not look like any guarantee to = >me, =3D >>> not in threaded application.=3D20=3D >>=20 >> If the program prints "running" then all threads have been created. >>=20 >> It eventually prints "running". >>=20 >> Therefore all threads are created. >>=20 >> --- >>=20 >> The things wrong with CM3's pthreads threading are NOT subtle. >> The runtime completely freezes up, ctrl-C stops working, and other >> such things. >>=20 >> Mika From dragisha at m3w.org Fri Apr 27 20:13:20 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 20:13:20 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> References: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> Message-ID: This particular deadlock/fix is observed and fixed for AMD64_LINUX. First change is just because it is same pattern. I ddidn't check if that code is used at all. Second change is our fix. With this, Mika's threadtest -tests alloc works. This is very probably fix for lots of situations tripped by his test and also for applications with heavy heap usage. dd p.s. Olaf/Michael, please teach me (again) how to commit this . It was long time since I commited anything to CVS :). Index: src/thread/PTHREAD/ThreadPThread.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v retrieving revision 1.259 diff -U 2 -r1.259 ThreadPThread.m3 --- src/thread/PTHREAD/ThreadPThread.m3 16 Jan 2011 21:25:21 -0000 1.259 +++ src/thread/PTHREAD/ThreadPThread.m3 27 Apr 2012 18:06:43 -0000 @@ -782,4 +782,5 @@ <*ASSERT act.state # ActState.Starting*> IF act.state # ActState.Stopped THEN + SetState(act, ActState.Stopping); SignalThread(act); INC(newlySent); @@ -971,4 +972,5 @@ <*ASSERT act.state # ActState.Starting*> IF act.state # ActState.Stopped THEN + SetState(act, ActState.Stopping); SignalThread(act); INC(newlySent); On Apr 27, 2012, at 3:04 PM, Antony Hosking wrote: > Platform? > Thread stack dump? > I assume it is a deadlock. > If not deadlock then what? > Diagnosis would then allow us to fix. > > Sent from my iPhone > > On Apr 27, 2012, at 3:26 AM, Dragi?a Duri? wrote: > >> Did anyone run combinations of tests and found minimal test sets where breaks happen? >> >> I tried read,alloc and it breaks. read only does not. >> >> From small number of tests I performed, it looks like RTAllocator is real culprit here. Most breaks happens while allocating, even one I saw in FileRd.Init() while running -tests read,alloc . From dragisha at m3w.org Fri Apr 27 21:30:16 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 21:30:16 +0200 Subject: [M3devel] Mika's thread test, -tests read Message-ID: Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. dd === (gdb) bt #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) at ../src/runtime/common/RTCollector.m3:1091 #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, thread=) at ../src/runtime/common/RTAllocator.m3:367 #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) info threads Id Target Id Frame * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 (gdb) thr 3 From wagner at elegosoft.com Fri Apr 27 22:13:35 2012 From: wagner at elegosoft.com (mail.elegosoft.com) Date: Fri, 27 Apr 2012 22:13:35 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: References: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> Message-ID: <20120427221335.699cc2ed.wagner@elegosoft.com> On Fri, 27 Apr 2012 20:13:20 +0200 Dragi?a Duri? wrote: > This particular deadlock/fix is observed and fixed for AMD64_LINUX. First change is just because it is same pattern. I ddidn't check if that code is used at all. Second change is our fix. > > With this, Mika's threadtest -tests alloc works. This is very probably fix for lots of situations tripped by his test and also for applications with heavy heap usage. > > dd > > p.s. Olaf/Michael, please teach me (again) how to commit this . It was long time since I commited anything to CVS :). If you've got the change in a workspace checked out via cvs/ssh, you just need to call `cvs commit' or `cvs commit -m "some meaningful log message"'. I assume that you have ssh access to m3.elegosoft.com. If not, Mike can set it up for you if you provide a key, or I can commit your changes if there are only a few of them. You may want to read http://www.elegosoft.com/en/solutions/modula-3/cvs-ssh-access.html if you haven't got ssh access yet. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Apr 27 22:21:22 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 27 Apr 2012 16:21:22 -0400 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> <20120426203603.GF4670@topoi.pooq.com> <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> Message-ID: <20120427202122.GF30181@topoi.pooq.com> On Thu, Apr 26, 2012 at 11:31:02PM +0200, Dragi?a Duri? wrote: > And still - ADDRESS type is 64bit. No 48, no 54 - but 64. As all (L|I)?LP64 pointer types are. Exactly! -- hendrik From dragisha at m3w.org Fri Apr 27 22:51:42 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 22:51:42 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: Message-ID: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> Another one, pretty "clean". Other threads are using their local memory, nothing shared execpt, of course, heap. Also, no visible pattern (yet) in other thread states/stacks when one of them breaks at this point. This, an RTCollector.Move() reported earlier, are two breaks in this test. === Creating nxread threads...[New Thread 0x7ffff7fd1700 (LWP 24756)] [New Thread 0x7ffff77d0700 (LWP 24757)] [New Thread 0x7ffff6fcf700 (LWP 24758)] done running...printing oldest/median age/newest ..........laziest thread is 0/0/0 (tests: nxread 0/0/0) ..........laziest thread is 0/0/0 (tests: nxread 0/0/0) . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7fd1700 (LWP 24756)] 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 44 IF (rd.buff = NIL) THEN (gdb) bt #0 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 #1 0x000000000041831d in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 #2 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 #3 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #4 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #5 0x0000003bed807d90 in start_thread (arg=0x7ffff7fd1700) at pthread_create.c:309 #6 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) info threads Id Target Id Frame 4 Thread 0x7ffff6fcf700 (LWP 24758) "threadtest" UnsafeRd__FastGetChar (rd=) at ../src/rw/Rd.m3:44 3 Thread 0x7ffff77d0700 (LWP 24757) "threadtest" 0x000000000044f405 in ThreadPThread__LockMutex (m=) at ../src/thread/PTHREAD/ThreadPThread.m3:115 * 2 Thread 0x7ffff7fd1700 (LWP 24756) "threadtest" 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 1 Thread 0x7ffff7fd3700 (LWP 24752) "threadtest" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 (gdb) On Apr 27, 2012, at 9:30 PM, Dragi?a Duri? wrote: > Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. From dragisha at m3w.org Fri Apr 27 23:11:51 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 23:11:51 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> Message-ID: <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Yes. [New Thread 0x7ffff7fd1700 (LWP 24695)] [New Thread 0x7ffff77d0700 (LWP 24696)] [New Thread 0x7ffff6fcf700 (LWP 24697)] done running...printing oldest/median age/newest . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff77d0700 (LWP 24696)] 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) bt ... I am using unchanged thread test from m3core/tests/thread with only -tests nxread as argument. On AMD64_LINUX, mostly, although I had breaks on AMD64_DARWIN too. I'll print future breaks with C stacks. dd On Apr 27, 2012, at 11:03 PM, Antony Hosking wrote: > Is this one a SIGSEGV? > > On Apr 27, 2012, at 3:30 PM, Dragi?a Duri? wrote: > >> Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. >> >> dd >> === >> (gdb) bt >> #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) >> at ../src/runtime/common/RTCollector.m3:409 >> #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) >> at ../src/runtime/common/RTHeapMap.m3:202 >> #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:62 >> #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 >> #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) >> at ../src/runtime/common/RTCollector.m3:1091 >> #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 >> #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >> #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, >> thread=) at ../src/runtime/common/RTAllocator.m3:367 >> #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 >> #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 >> #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 >> #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 >> #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 >> #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 >> #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 >> #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 >> #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 >> #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 >> (gdb) info threads >> Id Target Id Frame >> * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, >> cp=) at ../src/runtime/common/RTCollector.m3:409 >> 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> (gdb) thr 3 >> > From dragisha at m3w.org Sat Apr 28 08:49:25 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 08:49:25 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Message-ID: What is stack redzone? Undetected stack overflows or almost overflows? It's not only AMD64_* if it's any consolation: :) frodo:dragisha/pts/0: m3/thread/src% ../LINUXLIBC6/threadtest -tests read,alloc Writing file...done Creating read threads...done Creating alloc threads...done running...printing oldest/median age/newest . *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80792f0 = Move + 0x54 in ../src/runtime/common/RTCollector.m3 *** On Apr 27, 2012, at 11:34 PM, Antony Hosking wrote: > I wonder if we are not seeing the stack redzone on x86-64 and so losing references. > > On Apr 27, 2012, at 5:11 PM, Dragi?a Duri? wrote: > >> Yes. >> [New Thread 0x7ffff7fd1700 (LWP 24695)] >> [New Thread 0x7ffff77d0700 (LWP 24696)] >> [New Thread 0x7ffff6fcf700 (LWP 24697)] >> done >> running...printing oldest/median age/newest >> . >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7ffff77d0700 (LWP 24696)] >> 0x00000000004374e5 in RTCollector__Move (self=, cp=) >> at ../src/runtime/common/RTCollector.m3:409 >> 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; >> (gdb) bt >> ... >> >> I am using unchanged thread test from m3core/tests/thread with only -tests nxread as argument. On AMD64_LINUX, mostly, although I had breaks on AMD64_DARWIN too. >> >> I'll print future breaks with C stacks. >> >> dd >> >> On Apr 27, 2012, at 11:03 PM, Antony Hosking wrote: >> >>> Is this one a SIGSEGV? >>> >>> On Apr 27, 2012, at 3:30 PM, Dragi?a Duri? wrote: >>> >>>> Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. >>>> >>>> dd >>>> === >>>> (gdb) bt >>>> #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) >>>> at ../src/runtime/common/RTCollector.m3:409 >>>> #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:202 >>>> #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:62 >>>> #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:57 >>>> #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:57 >>>> #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 >>>> #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) >>>> at ../src/runtime/common/RTCollector.m3:1091 >>>> #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 >>>> #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >>>> #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>>> #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>>> #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, >>>> thread=) at ../src/runtime/common/RTAllocator.m3:367 >>>> #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 >>>> #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 >>>> #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 >>>> #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 >>>> #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 >>>> #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 >>>> #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 >>>> #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 >>>> #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 >>>> #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 >>>> (gdb) info threads >>>> Id Target Id Frame >>>> * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, >>>> cp=) at ../src/runtime/common/RTCollector.m3:409 >>>> 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> (gdb) thr 3 >>>> >>> >> > From dragisha at m3w.org Sat Apr 28 09:57:59 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 09:57:59 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Message-ID: RTFM helps, as always? No, I don't think it is redzone. BUT. One run: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4200 thread 0x10f] 0x0000000100037360 in RTCollector__Move (self=Cannot access memory at address 0xffffffffffffff77 ) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) ===== Next run: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4204 thread 0x40f] 0x0000000100017e6b in FileRd__Init (rd=Cannot access memory at address 0xffffffffffffffa7 ) at ../src/rw/FileRd.m3:44 44 IF (rd.buff = NIL) THEN ===== Next: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4207 thread 0x1703] 0x0000000100037360 in RTCollector__Move (self=Cannot access memory at address 0xffffffffffffff77 ) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) p hdr Cannot access memory at address 0xffffffffffffffdf << local variable ===== And so on? Break in FileRd.Init() happens after AllocTraced() takes LongAlloc() route. Break in Move happens along AllocTraced->CollectEnough. Interesting thing - previous call to AllocTraced took a LongAlloc() route. C trace, in Move() break: ===== (gdb) set lang c (gdb) bt #0 0x0000000100037360 in RTCollector__Move (self=0x100953c60, cp=0x100e50018) at ../src/runtime/common/RTCollector.m3:409 #1 0x00000001000358ca in RTHeapMap__Walk (x=0x0, pc=0x1009c0028, v=0x100098a88) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x0000000100034fb2 in RTHeapMap__DoWalkRef (t=0x1, a=0x100083de8, v=0x1009c0028) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100087898, a=0x100084848, v=0x1009c0018) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100d09a30, a=0x100084a48, v=0x1009c0018) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x0000000100034f21 in RTHeapMap__WalkRef (h=0x2018, v=0x1009c0010) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x000000010003986a in RTCollector__CleanBetween (h=0x0, he=0x1009c0010, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091 #7 0x0000000100039674 in RTCollector__CleanPage (page=0x1009d0000) at ../src/runtime/common/RTCollector.m3:1064 #8 0x0000000100038dd5 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #9 0x0000000100038532 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #10 0x000000010003820f in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 ===== Lines can differ, as I've put few RTIO.* lines in RTAllocator/Collector. On Apr 28, 2012, at 8:49 AM, Dragi?a Duri? wrote: > What is stack redzone? Undetected stack overflows or almost overflows? From dragisha at m3w.org Sat Apr 28 10:02:40 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 10:02:40 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> References: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> Message-ID: (this and previous email - AMD64_DARWIN) r -tests read,alloc @M3paranoidgc Starting program: /Users/dragisha/m3/thread/AMD64_DARWIN/threadtest -tests read,alloc @M3paranoidgc ... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4249 thread 0x1703] 0x000000010003bba1 in RTCollector__RefSanityCheck (v=Cannot access memory at address 0xffffffffffffffa7 ) at ../src/runtime/common/RTCollector.m3:1702 1702 tc := h.typecode; (gdb) set lang c (gdb) bt #0 0x000000010003bba1 in RTCollector__RefSanityCheck (v=0x0, cp=0x100980958) at ../src/runtime/common/RTCollector.m3:1702 #1 0x00000001000358ca in RTHeapMap__Walk (x=0x0, pc=0x100e20028, v=0x100098a88) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x0000000100034fb2 in RTHeapMap__DoWalkRef (t=0x1, a=0x100083de8, v=0x100e20028) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100087898, a=0x100084848, v=0x100e20018) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100e0f9f0, a=0x100084a48, v=0x100e20018) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x0000000100034f21 in RTHeapMap__WalkRef (h=0x2018, v=0x100e20010) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x000000010003b8dc in RTCollector__SanityCheck (self=0x100e20000) at ../src/runtime/common/RTCollector.m3:1660 #7 0x000000010003b618 in RTCollector__After (self=0x100e0fad0) at ../src/runtime/common/RTCollector.m3:1630 #8 0x0000000100035d35 in RTHeapRep__InvokeMonitors (before=0 '\0') at ../src/runtime/common/RTHeapRep.m3:59 #9 0x0000000100039305 in RTCollector__CollectSomeInStateFive () at ../src/runtime/common/RTCollector.m3:984 #10 0x000000010003856e in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:725 #11 0x000000010003820f in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #12 0x0000000100033d73 in RTAllocator__AllocTraced (dataSize=0, dataAlignment=8216, thread=0x8) at ../src/runtime/common/RTAllocator.m3:368 #13 0x0000000100033692 in RTAllocator__GetOpenArray (def=0x200026, s=0x100087898) at ../src/runtime/common/RTAllocator.m3:297 #14 0x00000001000329b2 in RTHooks__AllocateOpenArray (defn=0x100f2d468, s=0x100087898) at ../src/runtime/common/RTAllocator.m3:144 #15 0x0000000100002b32 in Main__AApply (cl=0x100e0fd80) at ../src/Main.m3:283 #16 0x0000000100050849 in ThreadPThread__RunThread (me=0x1703) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #17 0x000000010005050e in ThreadPThread__ThreadBase (param=0x100a01b00) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #18 0x00007fff84f908bf in _pthread_start () #19 0x00007fff84f93b75 in thread_start () This time - previous branch was not AllocTraced()->LongAlloc() dd On Apr 27, 2012, at 11:06 PM, Antony Hosking wrote: > Similarly, I suspect rd is corrupted on line 44 of FileRd.m3. > These all point to a collector bug. > Need to run with @M3paranoidgc to trigger the bug at collection time rather than later on when the mutator code is running. From dragisha at m3w.org Sat Apr 28 10:09:32 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 10:09:32 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> Message-ID: <6B6C6981-55E6-45ED-B2A6-E86A0853A23C@m3w.org> With paranoidgc errors are happening in/after AllocTraced() calls happening after AllocTraced() going short route. But not all happen here. I caught few in FileRd.Init(), again. On Apr 28, 2012, at 10:02 AM, Dragi?a Duri? wrote: > r -tests read,alloc @M3paranoidgc > Starting program: /Users/dragisha/m3/thread/AMD64_DARWIN/threadtest -tests read,alloc @M3paranoidgc > ... > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 > [Switching to process 4249 thread 0x1703] > 0x000000010003bba1 in RTCollector__RefSanityCheck (v=Cannot access memory at address 0xffffffffffffffa7 > ) at ../src/runtime/common/RTCollector.m3:1702 > 1702 tc := h.typecode; -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 28 11:10:42 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Apr 2012 09:10:42 +0000 Subject: [M3devel] ProcessEachStack duplicates StopWorld/StartWorld? Message-ID: Tony, can ProcessEachStack not have all the stop/start code duplicated and instead look more like: StopWorld act := me.next; WHILE act # me DO ProcessOther(act) act := act.next; END StartWorld ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 28 11:29:11 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 11:29:11 +0200 Subject: [M3devel] ProcessEachStack duplicates StopWorld/StartWorld? In-Reply-To: References: Message-ID: I think it can. I've fixed that loop also, just to be sure :). On Apr 28, 2012, at 11:10 AM, Jay K wrote: > Tony, can ProcessEachStack not have all the stop/start code > duplicated and instead look more like: > > > StopWorld > act := me.next; > WHILE act # me DO > ProcessOther(act) > act := act.next; > END > StartWorld > > > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 28 15:14:55 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 15:14:55 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> Message-ID: <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> Mika said it does not happen with user threads. But he also said he is using pm3 mostly? So question is - did he run it with cm3, any version, with user threads. What are build parameters for cm3 with user threads? On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > That means it is even more serious. > Can we verify that it only happens with pthread threading? > > Sent from my iPad > > On Apr 28, 2012, at 1:49 AM, Dragi?a Duri? wrote: > >> It's not only AMD64_* if it's any consolation: :) From mika at async.caltech.edu Sat Apr 28 18:50:38 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 28 Apr 2012 09:50:38 -0700 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> Message-ID: <20120428165038.E59451A205B@async.async.caltech.edu> Yes I have done it with user threads on CM3. (BTW, that is the configuration I always use on Darwin and Linux for "work".) There are a few ways of doing the configuration. The main thing is that the file m3-libs/m3core/src/thread/m3makefile contains the code >>> include_dir ("Common") if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") include_dir ("WIN32") else if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) include_dir("PTHREAD") else include_dir (OS_TYPE) end end <<< NO_USER_THREADS and USE_PTHREADS come from the config file. Mika =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Mika said it does not happen with user threads. But he also said he is = >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = >version, with user threads. > >What are build parameters for cm3 with user threads?=20 > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > >> That means it is even more serious. >> Can we verify that it only happens with pthread threading? >>=20 >> Sent from my iPad >>=20 >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > wrote: >>=20 >>> It's not only AMD64_* if it's any consolation: :) From jay.krell at cornell.edu Sun Apr 29 01:59:47 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Apr 2012 23:59:47 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <20120428165038.E59451A205B@async.async.caltech.edu> References: , <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com>, <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org>, , , <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com>, <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org>, <20120428165038.E59451A205B@async.async.caltech.edu> Message-ID: To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. - Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sun Apr 29 19:40:51 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 29 Apr 2012 18:40:51 +0100 (BST) Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: Message-ID: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> Iconic Modula-3 threads would be user-level transparent threads of machine threads, but then you would need threading system to cope with. I believe that current system is OK respect PTHREADS as much as is, this is specially true if there isn't one application that use threads of machine-level likely easier than other application users of them (see for example cvsup), cvsup has strong reliance on network idle times to decompress and use disk files to continue downloading over a two channel communication space, if you have server-side SMP-threads, then it's not easier to use them accordingly, because you still may have lower latencies queuing them and proportionately them to your users (your system will queue them as FIFO), but while your threads might finish connection faster, other user-level threads might need them more time to finish so they will be locked until (due network considerations and system dequeuing) clients get their messages off-time also, which is not fair if you are downloading small bits of code after other's longer chunks of code. I learned this while downloading with user-level threads and faster than with network same conditions and same machine with p-threads'ed systems longer finish time. Now this is counter-wise effect, as I got this while downloading from user-level thread system. Thanks in advance Thanks in advance http://modula3.elegosoft.com/cm3/ --- El s?b, 28/4/12, Jay K escribi?: De: Jay K Asunto: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? Para: "Mika Nystrom" , dragisha at m3w.org CC: "m3devel" Fecha: s?bado, 28 de abril, 2012 18:59 To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. ?- Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 29 23:01:39 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Apr 2012 21:01:39 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <26C159EB-EDC6-453C-A8EE-2F1AAAF0E170@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> <20120428165038.E59451A205B@async.async.caltech.edu> , <26C159EB-EDC6-453C-A8EE-2F1AAAF0E170@gmail.com> Message-ID: Ok, I can't argue with that. - Jay CC: mika at async.caltech.edu; dragisha at m3w.org; m3devel at elegosoft.com From: antony.hosking at gmail.com Subject: Re: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? Date: Sat, 28 Apr 2012 19:58:28 -0500 To: jay.krell at cornell.edu I'm just being conservative. Let's fix bugs before refactoring further. Sent from my iPad On Apr 28, 2012, at 6:59 PM, Jay K wrote: To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. - Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 29 23:11:36 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 29 Apr 2012 17:11:36 -0400 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <20120429211136.GA31736@topoi.pooq.com> On Sun, Apr 29, 2012 at 06:40:51PM +0100, Daniel Alejandro Benavides D. wrote: > (see for example cvsup), cvsup has strong reliance on network idle > times Speaking of cvsup, I seem to remember it stopped working, perhaps because of thread implementatino problems. Is it back in order yet? -- hendrik From jay.krell at cornell.edu Sun Apr 29 23:20:58 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Apr 2012 21:20:58 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <20120429211136.GA31736@topoi.pooq.com> References: , <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com>, <20120429211136.GA31736@topoi.pooq.com> Message-ID: We fixed it a long time ago. The problem was: Usually fork() is followed very soon by exec(). i.e. the way Posix programs (processes) often run sub-programs (processes) is via fork and exec. This is ok. No problem. However there is another pattern of use of fork where "servers" call fork for each "client". They don't exec. It is something like creating a thread. Except that everything is read-only/copy-on-write, not really shared. This is useful if servers have an expensive initialization, and don't need to share per-client. Cvsup does that. When fork is not followed by exec, whatever Modula-3 user threads existed in the "parent" process, still exist in the "child" process. The same is NOT true with pthreads. cvsup depended on the threads all surviving fork. We fixed cvsup to recreate its threads in the child process, and to fix user threads to NOT have threads survive fork, except the one calling fork. This highlighted other problems -- the existance of and possible need to use pthread_atfork. I'm not really explaining it all, but mostly. Look up pthread_atfork. - Jay > Date: Sun, 29 Apr 2012 17:11:36 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? > > On Sun, Apr 29, 2012 at 06:40:51PM +0100, Daniel Alejandro Benavides D. wrote: > > (see for example cvsup), cvsup has strong reliance on network idle > > times > > Speaking of cvsup, I seem to remember it stopped working, perhaps > because of thread implementatino problems. Is it back in order yet? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 29 23:49:22 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 29 Apr 2012 16:49:22 -0500 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427174948.9BB191A205B@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> <20120427174948.9BB191A205B@async.async.caltech.edu> Message-ID: <4F9DB762.3030608@lcwb.coop> On 04/27/2012 12:49 PM, Mika Nystrom wrote: > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >> I do not doubt they are created. Probably not an issue with 3 threads = >> here, 3 threads there, but it can be if one relies on "must be created = >> after some arbitrary time" in any synchronization. I did, and SRC people = >> did, at least in two places. I just don't see it as a good practice. > > Yes I have had that bug in my programs a few times. > > But to be really fair it's not that you're assuming that another > thread is created by a certain time but you're assuming that it has > done something by the time the first thread needs to do something else. > In the examples of the sort you describe it is usually that the newly > created thread has "had time to initialize" (in some way). My bug with > this was of this nature: > > thread A: > > ... Thread.Fork(b)... wait... LOCK(b.mu) > > Thread B: > > ... self.mu := NEW(MUTEX) ... > > Oops! works on some threading implementations (user threads). > Instant segfault on others! As I recall, this is the reason Thread.T <: MUTEX. Otherwise, there would be chicken-egg cases like this where you need a mutex to protect the allocation of a mutex and have no dependable way to get one. > > Have fun with the thread tester. It doesn't find any problems with > user threads. > > I should probably have dug into the pthreads myself long ago but it's > always so far down the todo list, and all my CM3 installations use user > threads by necessity. If you can improve the pthreads I think it would > make me much happier about CM3 in general. I still use PM3 as much as > possible... > > Mika > > >> >> BTW, your test is excellent stress machine. My laptops hate it, = >> probably, till now :). Right now I am focused on an allocation race = >> issue and I hope to fix it in few hours/a day. >> >> On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: >> >>> =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>> ... >>>> I am reading your source code just now. And one thing caught my eye: = >> =3D >>>> "Each type of thread starts by sleeping for a while, to give the = >> other =3D >>>> threads a chance to be created." Does not look like any guarantee to = >> me, =3D >>>> not in threaded application.=3D20=3D >>> =20 >>> If the program prints "running" then all threads have been created. >>> =20 >>> It eventually prints "running". >>> =20 >>> Therefore all threads are created. >>> =20 >>> --- >>> =20 >>> The things wrong with CM3's pthreads threading are NOT subtle. >>> The runtime completely freezes up, ctrl-C stops working, and other >>> such things. >>> =20 >>> Mika > From dragisha at m3w.org Fri Apr 6 21:38:30 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 6 Apr 2012 21:38:30 +0200 Subject: [M3devel] cm3ide, ESC, cm3jvm(?) Message-ID: <1DDF651B-C60C-45A3-8DF4-005216FE67ED@m3w.org> Recently I found time to get cm3ide up? My thanks to Bill, Farshad, Randy and Olaf! Also, I see there is ESC now in cm3 /... Can we expect complete version, or do we already have that? How to use? Also II - is there any chance to get cmass JVM opensourced? I have many ideas how to make that useful.. TIA, dd From dabenavidesd at yahoo.es Fri Apr 6 22:43:35 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 6 Apr 2012 21:43:35 +0100 (BST) Subject: [M3devel] cm3ide, ESC, cm3jvm(?) In-Reply-To: <1DDF651B-C60C-45A3-8DF4-005216FE67ED@m3w.org> Message-ID: <1333745015.46036.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: nice idea, JVM + CMM3 is nice product. ESC was a nice idea too, but if you see its results in Java I don't know if it has been a "market" success (lost type checking information can make a better realization of it, like in casting errors, etc), although it was not intended for that but to be useful in the research area of CS, specially education. I would like the idea of using typed interpretation of objects on it for Modular checking of other jvm mechanics (though Java Object Model is inherently different from that of a Module-oriented VM, but since it's almost an operating system): for instance a new type-safe object make of Objects, but in that sense, you have (mandatory) to be sound to tough compiler purists specially in Java attempt that but still not quite like Modula-3 Module semantics purity. So it's hard to talk and hard technology to crasp on, but sure, none of them will be disliked by such a beast, anyone agree? Thanks in advance --- El vie, 6/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] cm3ide, ESC, cm3jvm(?) > Para: "m3devel" > Fecha: viernes, 6 de abril, 2012 14:38 > Recently I found time to get cm3ide > up? My thanks to Bill, Farshad, Randy and Olaf! > > Also, I see there is ESC now in cm3 /... Can we expect > complete version, or do we already have that? How to use? > > Also II - is there any chance to get cmass JVM opensourced? > I have many ideas how to make that useful.. > > TIA, > dd > > From dabenavidesd at yahoo.es Thu Apr 12 23:09:00 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 12 Apr 2012 22:09:00 +0100 (BST) Subject: [M3devel] A Baby Modula-3 Operating Environment hosted on SPIN OS for Language Researchers Message-ID: <1334264940.21694.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I was reading about Meta-Environments (and finding some sort of it for Modula-3) and found MetaBETA (Scandinavian school OO programming language), that uses Dynamic linking and loading of SPIN mechanism for itself: http://www.daimi.au.dk/PB/506/PB-506.pdf Can't we make our own flavor for it? Meta-BM3. We could create the drivers needed for it in a Modula-3 fashion (actually as it happens the side effects of UNSAFE modules could be verified by dynamic type tests and/or verified assembly like in a JVM-style ?-code not to corrupt the verified ones) or by memory watchdog as I believe Alpha architecture had a nice feature to warn against unwanted access on certain memory regions, hadn't it? Thanks in advance From penn43 at gmx.com Thu Apr 19 00:10:24 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Thu, 19 Apr 2012 00:10:24 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120418221024.27330@gmx.com> Dear Modula-3 developers, I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. I hope you can help me clarify some points and dispel some doubts. The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. I thank you in advance. Best regards, Marresh P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). From rcolebur at SCIRES.COM Thu Apr 19 01:13:26 2012 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 18 Apr 2012 19:13:26 -0400 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: Marresh: I've programmed in a number of different languages. For me, I've found that Modula-3 is the best for most of what I do. Further, I've found that the concepts in Modula-3 help you think through things in a more complete manner, thereby making you a better programmer. When I've been forced to use other languages, I've often found myself starting out in Modula-3 and then translating to the other language once the main concepts are defined. Just because Modula-3 is touted as a systems programming language doesn't mean it is too complex for simpler projects; however, if you are only wanting to write very simple, independent programs that won't ever have any parts reused anywhere else, you may find the initial discipline of interfaces and implementations a bit verbose. The language itself is really quite compact, given its power, and the concepts are straightforward and don't throw you curve balls. I can't really comment much about Oberon as I haven't used it much. As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. I'm not sure if anyone has done any recent bindings to GUI toolkits. Hope this helps. --Randy Coleburn -----Original Message----- From: penn43 at gmx.com [mailto:penn43 at gmx.com] Sent: Wednesday, April 18, 2012 6:10 PM To: m3devel at elegosoft.com Subject: [M3devel] Modula-3 questions Dear Modula-3 developers, I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. I hope you can help me clarify some points and dispel some doubts. The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. I thank you in advance. Best regards, Marresh P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). From mika at async.caltech.edu Thu Apr 19 02:25:50 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 18 Apr 2012 17:25:50 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: <20120419002550.798361A205B@async.async.caltech.edu> penn43 at gmx.com writes: ... >P.S. is the creation and maintenance of module interfaces all that trouble? I >read somewhere that it is a pain, and that the inconvenience of it would only >be paid off when one has to manage large projects (which is not my case). I personally find the Modula-3 interface design to be one of the best parts of the language. It would maybe be nice if it had more levels of qualification, like Java, but that's a minor issue. The way that it's almost impossible to get name clashes is a much bigger advantage. And you find that the small effort required to type your procedure prototypes pays off rather quickly... Finally, I could ask you what kind of programming you intend to do that you are certain won't eventually turn into large projects :-) Mika From dabenavidesd at yahoo.es Thu Apr 19 03:52:27 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 02:52:27 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> Message-ID: <1334800347.21677.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Threads are common use of Modula-3 Standard Interfaces because basically Modula-3 was born in Modula-2+ programming environments of multi-processor or mainframes (it was a kind of ahead of its time for real). If you don't need Thread I guess you don't want to use several options like OS support (like Systems programming) and stuff, Modula-3 has its own environment for safe-threads (embedded) threads, though its use is not mandatory and not successful in any SMP environment (by default nowadays). GUIs are not mandatory supported and constructed bottom up, if you want a new GUI system, you want a threaded one (that's Modula-2+ supposition since, you want not much overhead so be alerted in any event or for stronger distributed multi-window system like current Trestle is designed). In any event, there is a KDevelop project of Modula-3 but that was quite some time ago. Though there is some support in Gtk, but again talking about a small size project that is overkilling, Gtk library dependencies on C makes a not want to develop for them, so avoid them right? Simple languages are characterized by the smaller language definitions, this the case with C++, C, Java (the last two are called 'simple'), but spirit of Oberon was the same foundation of Modula-3, simpler is better, cleaner and still good support for better programming productivity (say Oberon for ?-controllers and small-footprint environments) so it gets rid of everything it can be too onerous (including big libraries and etc, but this days libraries and smaller memories are bigger than those days, so) Also Oberon was designed for compiler designer, so you do the math. Thanks in advance --- El mi?, 18/4/12, penn43 at gmx.com escribi?: > De: penn43 at gmx.com > Asunto: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 18 de abril, 2012 17:10 > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. > I have already had a look at the language, and it certainly > looks interesting. However, I still have some misgivings > about starting learning Modula-3, since it would be a > considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some > doubts. > > The first point is that I would neither be working on large > projects, nor doing systems programming. I understand these > were the two major strengths of Modula-3, but neither would > be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > Secondly, could you please help me understand what are the > reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > So, again, keeping in mind that I don't need the advanced > features mentioned above, nor multithreading, does it make > any sense for me to choose Modula-3 instead of Oberon, or > Object Pascal? > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces > all that trouble? I read somewhere that it is a pain, and > that the inconvenience of it would only be paid off when one > has to manage large projects (which is not my case). > > From dragisha at m3w.org Thu Apr 19 10:36:56 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Apr 2012 10:36:56 +0200 Subject: [M3devel] Modula-3 questions In-Reply-To: References: <20120418221024.27330@gmx.com> Message-ID: <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> Maybe of interest to original poster - Modula-3 development tools are extremely lightweight and compact. Easy to create and maintain any project, be it small or not. And portable to extreme. On Apr 19, 2012, at 1:13 AM, Coleburn, Randy wrote: > As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." This is new one to me, but - in the best Modula-3 tradition - it will be reused a lot :). > > WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. Not least of these being concepts borrowed from C++ :) > > I'm not sure if anyone has done any recent bindings to GUI toolkits. I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Apr 19 16:10:29 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:10:29 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> References: <20120418221024.27330@gmx.com> <1DD70EA9-1543-4322-85D2-7FEE97ECEDCE@m3w.org> Message-ID: <4F901CD5.9050405@lcwb.coop> On 04/19/2012 03:36 AM, Dragi?a Duri? wrote: > Maybe of interest to original poster - Modula-3 development tools are extremely lightweight and compact. Easy to create and maintain any project, be it small or not. And portable to extreme. > > On Apr 19, 2012, at 1:13 AM, Coleburn, Randy wrote: > >> As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." > > This is new one to me, but - in the best Modula-3 tradition - it will be reused a lot :). > >> >> WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. > > Not least of these being concepts borrowed from C++ :) > >> >> I'm not sure if anyone has done any recent bindings to GUI toolkits. > > I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. I would be interested in this binding. From rodney_bates at lcwb.coop Thu Apr 19 16:54:06 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:54:06 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: References: <20120418221024.27330@gmx.com> Message-ID: <4F90270E.5030702@lcwb.coop> On 04/18/2012 06:13 PM, Coleburn, Randy wrote: > Marresh: > > I've programmed in a number of different languages. > > For me, I've found that Modula-3 is the best for most of what I do. > > Further, I've found that the concepts in Modula-3 help you think through things in a more complete manner, thereby making you a better programmer. > > When I've been forced to use other languages, I've often found myself starting out in Modula-3 and then translating to the other language once the main concepts are defined. > > Just because Modula-3 is touted as a systems programming language doesn't mean it is too complex for simpler projects; however, if you are only wanting to write very simple, independent programs that won't ever have any parts reused anywhere else, you may find the initial discipline of interfaces and implementations a bit verbose. > > The language itself is really quite compact, given its power, and the concepts are straightforward and don't throw you curve balls. > > I can't really comment much about Oberon as I haven't used it much. > > As for C and C++, I remember a quote from an instructor years ago that you may find interesting: "The good news about C++ versus C is that it is harder to shoot yourself in the foot, but the bad news is that when you do, you blow your whole leg off." > I don't really believe this, for several reasons. C++ does add some things that make it harder. For example, you can use library (library is not language, BTW) versions of arrays, at the usual costs of heap-allocation, sometimes unnecessary. But it only works if you use it. If you do an array-bounds thing, you can blow your leg off just as badly in C as in C++. C++ preserves C's broken half-treatment of arrays, with the same possibilities for these bugs. Meanwhile, C++ adds a lot of additional ways to shoot yourself in the foot. For example, the user-defined overloading system means you can add a function declaration and have existing calls silently switch from whatever function they used to call to your new one. Or the reverse. Deleting a declaration could result in existing calls on it silently switching to some other function, instead of giving compile errors, as you would expect. A nightmare if the code is anything but small. > WRT Java, my understanding is that the original designers borrowed some concepts from Modula-3, but that alone doesn't make up for other problems with Java. > > I'm not sure if anyone has done any recent bindings to GUI toolkits. > > Hope this helps. > > --Randy Coleburn > > > -----Original Message----- > From: penn43 at gmx.com [mailto:penn43 at gmx.com] > Sent: Wednesday, April 18, 2012 6:10 PM > To: m3devel at elegosoft.com > Subject: [M3devel] Modula-3 questions > > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some doubts. > > The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? > > Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. > So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? > > Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). > From rodney_bates at lcwb.coop Thu Apr 19 17:02:27 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 10:02:27 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120419002550.798361A205B@async.async.caltech.edu> References: <20120418221024.27330@gmx.com> <20120419002550.798361A205B@async.async.caltech.edu> Message-ID: <4F902903.8060807@lcwb.coop> On 04/18/2012 07:25 PM, Mika Nystrom wrote: > penn43 at gmx.com writes: > ... >> P.S. is the creation and maintenance of module interfaces all that trouble? I >> read somewhere that it is a pain, and that the inconvenience of it would only >> be paid off when one has to manage large projects (which is not my case). > > I personally find the Modula-3 interface design to be one of the best > parts of the language. It would maybe be nice if it had more levels of > qualification, like Java, but that's a minor issue. The way that it's > almost impossible to get name clashes is a much bigger advantage. The Java levels-of-qualification system is not at all what it looks like at first glance. Semantically, it's no more than a flat space, with names of things allowed to have dots in them (and no doubt white space and comments around the dots.) A.B has no more relation to A.C than Shooby_Do_Bop has to HeyDownHoDownDerryDerryDown. Yeah, I know it does reflect where the source files are located in your directory structure, but aside from having no semantic significance, that's only a cultural convention. The language explicitly permits implementors to search for source files otherwise. > > And you find that the small effort required to type your procedure > prototypes pays off rather quickly... > > Finally, I could ask you what kind of programming you intend to do that > you are certain won't eventually turn into large projects :-) > > Mika > From rodney_bates at lcwb.coop Thu Apr 19 16:45:53 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 19 Apr 2012 09:45:53 -0500 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120418221024.27330@gmx.com> References: <20120418221024.27330@gmx.com> Message-ID: <4F902521.8000105@lcwb.coop> On 04/18/2012 05:10 PM, penn43 at gmx.com wrote: > Dear Modula-3 developers, > > I am not a Modula-3 user, but I am considering becoming one. I have already had a look at the language, and it certainly looks interesting. However, I still have some misgivings about starting learning Modula-3, since it would be a considerable time investment and I am not even sure if Modula-3 is the right tool for me. > I hope you can help me clarify some points and dispel some doubts. > > The first point is that I would neither be working on large projects, nor doing systems programming. I understand these were the two major strengths of Modula-3, but neither would be useful in my case, as I would be programming mostly small- and medium-sized applications, not even industrial-level. What I need is simply a tool that can be used instead of C++ and Java. Modula-3 looks fine, because it promises to be simple. However, having read that Modula-3 was designed especially for industrial-strength and advanced uses, I am afraid that adopting Modula-3 as my development tool might be an overkill. Could you advise me in this regard? > C++ is 6 times more complicated than Modula-3, by reference manual page count, which is usually a reasonable, simple way to estimate complexity. Java is 8 times, though its reference manual is significantly less dense than most. Ada is 10 times. With room for some minor quibbles, Modula-3 has more useful programming features than any of these, thus the best "economy of concept", or ratio of real power to complexity. Java is especially low on this scale, since it is quite feeble, yet has an enormous reference manual. Particularly, all array- and record-like constructs are forcibly heap allocated whether you need it or not, with resulting coding overhead. You always have to allocate and either constantly NIL-check or create an argument in your head/comments that they are always non-NIL. This is usually scattered around your code. Unnecessary heap-allocation has execution space and time overhead too, but this would probably not be of concern to you. Modula-3 is also particularly good at minimizing interactions among language features. This makes it easier to learn/use a subset of the language, with less risk of tripping over something you haven't studied. That happens a _lot_ in C++ and Ada. If you ever eventually want to use more features, they are there, without having to relearn the superficial syntax, etc., of the basic stuff. > Secondly, could you please help me understand what are the reasons for which one may prefer Modula-3 over Oberon-2/Active Oberon? I have been considering Oberon too because, like Modula-3, it promises to be simple and minimalistic. > So, again, keeping in mind that I don't need the advanced features mentioned above, nor multithreading, does it make any sense for me to choose Modula-3 instead of Oberon, or Object Pascal? > If you prefer absolute minimal language complexity without regard for programming richness, as opposed to economy of concept, the Oberon family fares better by that criterion. But I think, even with your minimal goals, you will like some of the additional things Modula-3 has. > Lastly, what is the current availability of Modula-3 libraries? I have read that Modula-3 has a rich set of libraries, but that was many years ago. Are there any up-to-date libraries, fulfilling today's needs? I am mostly interested in GUI support (possibly bindings to some standard GUI toolkit, like GTK or QT, or wxWidgets), internet libraries and UTF-8 support. > > I thank you in advance. > > Best regards, > > Marresh > > P.S. is the creation and maintenance of module interfaces all that trouble? I read somewhere that it is a pain, and that the inconvenience of it would only be paid off when one has to manage large projects (which is not my case). > > From dabenavidesd at yahoo.es Thu Apr 19 18:30:36 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 17:30:36 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <4F902521.8000105@lcwb.coop> Message-ID: <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I think is a good comparison to say C++ is to Java what Modula-3 is to Oberon. The typing model is similarly relatively augmented from one to the other and UNSAFE features are allowed in the former without control over it (where is in Modula-3 is more confined to UNSAFE MODULEs). Also a machine independent code is not so in the object-code sense (though Modula-3 has its own scripting extension engine). Modula-3 OBJECT TYPEs are relative number ordered but other Record-Oriented languages may have a rather distinct type classification system. C++ just makes the multiple-inheritance support system a big headache for every programmer accustomed to handle single-inheritance languages, but not counter wise case In easy of use Modula-3 hands its own distinct picture of program in terms of Modules (which handle software re usability stronger than just Object-type systems). Object Oberon instead focuses on that counter-idea. C++ is a lot like Java in the Class-word sense, which is hard to deal with when you don't have explicit INTERFACE TYPEs like Modula-3 ones (you can create object from OBJECTs their selves and INTERFACES TYPEs), Java still makes an emulation via interfaces but are not just for abstract classes, and not all kind of classes (if you don't program in that way), and you sort to adhere to that or leave it. Modula-3 modularity is more uniform from that. C++ has the template mechanism but it isn't that well designated to be a GENERIC TYPE but some sort of template of code of untyped code. This can be powerful if you want to have polymorphism but you can have a hard type figuring out what kind of template class you want in any case. This is a Modula-3 advantage since most of the type system developed after them are really oriented towards controlling that complexity via Compile-type checking (which still can make the case for a Extended-Type Checker concept) Thanks in advance --- El jue, 19/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 09:45 > > > On 04/18/2012 05:10 PM, penn43 at gmx.com > wrote: > > Dear Modula-3 developers, > > > > I am not a Modula-3 user, but I am considering becoming > one. I have already had a look at the language, and it > certainly looks interesting. However, I still have some > misgivings about starting learning Modula-3, since it would > be a considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > > I hope you can help me clarify some points and dispel > some doubts. > > > > The first point is that I would neither be working on > large projects, nor doing systems programming. I understand > these were the two major strengths of Modula-3, but neither > would be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > > > C++ is 6 times more complicated than Modula-3, by reference > manual page count, which is > usually a reasonable, simple way to estimate > complexity. Java is 8 times, though its > reference manual is significantly less dense than > most. Ada is 10 times. With room > for some minor quibbles, Modula-3 has more useful > programming features than any of these, > thus the best "economy of concept", or ratio of real power > to complexity. > > Java is especially low on this scale, since it is quite > feeble, yet has an enormous > reference manual. Particularly, all array- and > record-like constructs are forcibly heap > allocated whether you need it or not, with resulting coding > overhead. You always have > to allocate and either constantly NIL-check or create an > argument in your head/comments > that they are always non-NIL. This is usually > scattered around your code. Unnecessary > heap-allocation has execution space and time overhead too, > but this would probably not > be of concern to you. > > Modula-3 is also particularly good at minimizing > interactions among language features. > This makes it easier to learn/use a subset of the language, > with less risk of tripping > over something you haven't studied. That happens a > _lot_ in C++ and Ada. If you ever > eventually want to use more features, they are there, > without having to relearn the > superficial syntax, etc., of the basic stuff. > > > Secondly, could you please help me understand what are > the reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > > So, again, keeping in mind that I don't need the > advanced features mentioned above, nor multithreading, does > it make any sense for me to choose Modula-3 instead of > Oberon, or Object Pascal? > > > > If you prefer absolute minimal language complexity without > regard for programming richness, > as opposed to economy of concept, the Oberon family fares > better by that criterion. But I > think, even with your minimal goals, you will like some of > the additional things Modula-3 has. > > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > > > I thank you in advance. > > > > Best regards, > > > > Marresh > > > > P.S. is the creation and maintenance of module > interfaces all that trouble? I read somewhere that it is a > pain, and that the inconvenience of it would only be paid > off when one has to manage large projects (which is not my > case). > > > > > From microcode at zoho.com Thu Apr 19 18:51:29 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Thu, 19 Apr 2012 16:51:29 +0000 Subject: [M3devel] Fw: Modula-3 questions Message-ID: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> I sent this to Alejandro by mistake. It should have gone to the list. Sorry guys. -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. -----Original Message----- From: "Daniel Alejandro Benavides D." Date: Thu, 19 Apr 2012 17:30:36 To: ; Rodney M. Bates Subject: Re: [M3devel] Modula-3 questions Hi all: I think is a good comparison to say C++ is to Java what Modula-3 is to Oberon. The typing model is similarly relatively augmented from one to the other and UNSAFE features are allowed in the former without control over it (where is in Modula-3 is more confined to UNSAFE MODULEs). Also a machine independent code is not so in the object-code sense (though Modula-3 has its own scripting extension engine). Modula-3 OBJECT TYPEs are relative number ordered but other Record-Oriented languages may have a rather distinct type classification system. C++ just makes the multiple-inheritance support system a big headache for every programmer accustomed to handle single-inheritance languages, but not counter wise case In easy of use Modula-3 hands its own distinct picture of program in terms of Modules (which handle software re usability stronger than just Object-type systems). Object Oberon instead focuses on that counter-idea. C++ is a lot like Java in the Class-word sense, which is hard to deal with when you don't have explicit INTERFACE TYPEs like Modula-3 ones (you can create object from OBJECTs their selves and INTERFACES TYPEs), Java still makes an emulation via interfaces but are not just for abstract classes, and not all kind of classes (if you don't program in that way), and you sort to adhere to that or leave it. Modula-3 modularity is more uniform from that. C++ has the template mechanism but it isn't that well designated to be a GENERIC TYPE but some sort of template of code of untyped code. This can be powerful if you want to have polymorphism but you can have a hard type figuring out what kind of template class you want in any case. This is a Modula-3 advantage since most of the type system developed after them are really oriented towards controlling that complexity via Compile-type checking (which still can make the case for a Extended-Type Checker concept) Thanks in advance --- El jue, 19/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 09:45 > > > On 04/18/2012 05:10 PM, penn43 at gmx.com > wrote: > > Dear Modula-3 developers, > > > > I am not a Modula-3 user, but I am considering becoming > one. I have already had a look at the language, and it > certainly looks interesting. However, I still have some > misgivings about starting learning Modula-3, since it would > be a considerable time investment and I am not even sure if > Modula-3 is the right tool for me. > > I hope you can help me clarify some points and dispel > some doubts. > > > > The first point is that I would neither be working on > large projects, nor doing systems programming. I understand > these were the two major strengths of Modula-3, but neither > would be useful in my case, as I would be programming mostly > small- and medium-sized applications, not even > industrial-level. What I need is simply a tool that can be > used instead of C++ and Java. Modula-3 looks fine, because > it promises to be simple. However, having read that Modula-3 > was designed especially for industrial-strength and advanced > uses, I am afraid that adopting Modula-3 as my development > tool might be an overkill. Could you advise me in this > regard? > > > > C++ is 6 times more complicated than Modula-3, by reference > manual page count, which is > usually a reasonable, simple way to estimate > complexity. Java is 8 times, though its > reference manual is significantly less dense than > most. Ada is 10 times. With room > for some minor quibbles, Modula-3 has more useful > programming features than any of these, > thus the best "economy of concept", or ratio of real power > to complexity. > > Java is especially low on this scale, since it is quite > feeble, yet has an enormous > reference manual. Particularly, all array- and > record-like constructs are forcibly heap > allocated whether you need it or not, with resulting coding > overhead. You always have > to allocate and either constantly NIL-check or create an > argument in your head/comments > that they are always non-NIL. This is usually > scattered around your code. Unnecessary > heap-allocation has execution space and time overhead too, > but this would probably not > be of concern to you. > > Modula-3 is also particularly good at minimizing > interactions among language features. > This makes it easier to learn/use a subset of the language, > with less risk of tripping > over something you haven't studied. That happens a > _lot_ in C++ and Ada. If you ever > eventually want to use more features, they are there, > without having to relearn the > superficial syntax, etc., of the basic stuff. > > > Secondly, could you please help me understand what are > the reasons for which one may prefer Modula-3 over > Oberon-2/Active Oberon? I have been considering Oberon too > because, like Modula-3, it promises to be simple and > minimalistic. > > So, again, keeping in mind that I don't need the > advanced features mentioned above, nor multithreading, does > it make any sense for me to choose Modula-3 instead of > Oberon, or Object Pascal? > > > > If you prefer absolute minimal language complexity without > regard for programming richness, > as opposed to economy of concept, the Oberon family fares > better by that criterion. But I > think, even with your minimal goals, you will like some of > the additional things Modula-3 has. > > > Lastly, what is the current availability of Modula-3 > libraries? I have read that Modula-3 has a rich set of > libraries, but that was many years ago. Are there any > up-to-date libraries, fulfilling today's needs? I am mostly > interested in GUI support (possibly bindings to some > standard GUI toolkit, like GTK or QT, or wxWidgets), > internet libraries and UTF-8 support. > > > > I thank you in advance. > > > > Best regards, > > > > Marresh > > > > P.S. is the creation and maintenance of module > interfaces all that trouble? I read somewhere that it is a > pain, and that the inconvenience of it would only be paid > off when one has to manage large projects (which is not my > case). > > > > > From mika at async.caltech.edu Thu Apr 19 19:29:18 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 19 Apr 2012 10:29:18 -0700 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> References: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> Message-ID: <20120419172918.A32A91A205B@async.async.caltech.edu> But at the same time the Green Book (G. Nelson, ed., Systems Programming with Modula-3, Prentice-Hall 1991) is probably the best description of how to actually use object-oriented programming in practice that's ever been published... I once wrote to whoever now owns Prentice-Hall and asked their copyright clearance person for permission to photocopy chapters of that book for a class I was teaching. No response, not even "absolutely not." But most of it (all of it??) is available online. I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that if the hordes discover it, they will ruin it. One LONGINT is enough headaches for me. I find the unchanging nature of the language to be a huge advantage in what I do. Mika -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. From dknoto at next.com.pl Thu Apr 19 19:38:45 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Thu, 19 Apr 2012 19:38:45 +0200 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419172918.A32A91A205B@async.async.caltech.edu> References: <1856091956-1334854251-cardhu_decombobulator_blackberry.rim.net-292673570-@b1.c1.bise3.blackberry> <20120419172918.A32A91A205B@async.async.caltech.edu> Message-ID: <20120419193845.7206cc1e@wenus.next.com.pl> Dnia 2012-04-19, o godz. 10:29:18 Mika Nystrom napisa?(a): > > But at the same time the Green Book (G. Nelson, ed., Systems Programming > with Modula-3, Prentice-Hall 1991) is probably the best description of > how to actually use object-oriented programming in practice that's ever > been published... > It is a pity that Amazon does not send used books outside the U.S., the seller on eBay too. Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Thu Apr 19 20:00:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 19:00:25 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419172918.A32A91A205B@async.async.caltech.edu> Message-ID: <1334858425.89359.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: In terms of literature I believe by the long lapsus of history that has gone after that book, you don't need to understand much of it to notice that some people don't realize the language as of tremendous historic value, aided by negligent community outside. BTW Python it's one of the few that recognize its strong influence over it. But talking about history and then what happened, this matcvhes with what we are seeing: "Conferences, on how to program Object Oriented Programming"; my goodness, this is the Modula-3 history, what else are they looking for? Thanks in advance --- El jue, 19/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: microcode at zoho.com > CC: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 12:29 > > But at the same time the Green Book (G. Nelson, ed., Systems > Programming > with Modula-3, Prentice-Hall 1991) is probably the best > description of > how to actually use object-oriented programming in practice > that's ever > been published... > > I once wrote to whoever now owns Prentice-Hall and asked > their copyright > clearance person for permission to photocopy chapters of > that book > for a class I was teaching. No response, not even > "absolutely not." > But most of it (all of it??) is available online. > > I'm somewhat ambivalent about marketing Modula-3 too > hard. I fear that > if the hordes discover it, they will ruin it. One > LONGINT is enough > headaches for me. I find the unchanging nature of the > language to be > a huge advantage in what I do. > > Mika > > -----Original Message----- > From: microcode at zoho.com > Date: Thu, 19 Apr 2012 16:49:57 > To: Daniel Alejandro Benavides D. > Reply-To: microcode at zoho.com > Subject: Re: [M3devel] Modula-3 questions > > A big inhibitor to Modula-3 is the lack of books and > tutorials. CM3 has a great system running on tons of > platforms. But where can people learn to code Modula-3? > > I see this as the biggest obstacle. > > > From dabenavidesd at yahoo.es Thu Apr 19 21:20:54 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 19 Apr 2012 20:20:54 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120419193845.7206cc1e@wenus.next.com.pl> Message-ID: <1334863254.51331.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: In my native country (Colombia/South America) there isn't problem about redistributing copyrighted material provided that it is not for profit purposes. Or having acquirement rule in EU countries, (though the aftermath of Trading agreements might overcome that as well) might facilitate photocopies or microfilm distribution. In any case it will need some sort of Modula-3 foundation or something to validate the use of that material I guess. I like the idea of having it to use over Internet for instance in Amazon, etc, but I guess lobbying would be required. Having said that, DEC-SRC building in Palo Alto is being occupied by Amazon research Division according to Wikipedia: http://en.wikipedia.org/wiki/DEC_Systems_Research_Center I didn't make it to California, but I'm certain that we should go and ask over there. Thanks in advance --- El jue, 19/4/12, Dariusz Knoci?ski escribi?: > De: Dariusz Knoci?ski > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: m3devel at elegosoft.com, "Mika Nystrom" > Fecha: jueves, 19 de abril, 2012 12:38 > Dnia 2012-04-19, o godz. 10:29:18 > Mika Nystrom > napisa?(a): > > > > > But at the same time the Green Book (G. Nelson, ed., > Systems Programming > > with Modula-3, Prentice-Hall 1991) is probably the best > description of > > how to actually use object-oriented programming in > practice that's ever > > been published... > > > > It is a pity that Amazon does not send used books outside > the U.S., the seller > on eBay too. > > Best regards > Dariusz Knoci?ski. > From hendrik at topoi.pooq.com Fri Apr 20 04:32:39 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 19 Apr 2012 22:32:39 -0400 Subject: [M3devel] Modula-3 questions In-Reply-To: <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <4F902521.8000105@lcwb.coop> <1334853036.33850.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <20120420023238.GE5407@topoi.pooq.com> On Thu, Apr 19, 2012 at 05:30:36PM +0100, Daniel Alejandro Benavides D. wrote: > > Modula-3 modularity is more uniform from that. The nice thing about Module 3's modularity is that it's completely independent of procedures, object types, global variables, and all that. You can use the language the way you want to, and still be able to wrap up whatever kind of module makes sense for your application. -- hendrik From microcode at zoho.com Fri Apr 20 11:12:22 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Fri, 20 Apr 2012 09:12:22 +0000 Subject: [M3devel] Fw: Modula-3 questions Message-ID: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> I haven't found that book or any Modula-3 books online. I agree that things are often best left alone and often ruined by constant change and people who want to make things into other things they were never intended to be. I said something similar a few debates ago. I don't care what's popular as long as it still exists :-) ------Original Message------ From: Mika Nystrom To: microcode at zoho.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Fw: Modula-3 questions Sent: 19 Apr 2012 17:29 But at the same time the Green Book (G. Nelson, ed., Systems Programming with Modula-3, Prentice-Hall 1991) is probably the best description of how to actually use object-oriented programming in practice that's ever been published... I once wrote to whoever now owns Prentice-Hall and asked their copyright clearance person for permission to photocopy chapters of that book for a class I was teaching. No response, not even "absolutely not." But most of it (all of it??) is available online. I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that if the hordes discover it, they will ruin it. One LONGINT is enough headaches for me. I find the unchanging nature of the language to be a huge advantage in what I do. Mika -----Original Message----- From: microcode at zoho.com Date: Thu, 19 Apr 2012 16:49:57 To: Daniel Alejandro Benavides D. Reply-To: microcode at zoho.com Subject: Re: [M3devel] Modula-3 questions A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? I see this as the biggest obstacle. From rodney_bates at lcwb.coop Fri Apr 20 15:48:46 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 20 Apr 2012 08:48:46 -0500 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> References: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> Message-ID: <4F91693E.9000903@lcwb.coop> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: > I haven't found that book or any Modula-3 books online. > > I agree that things are often best left alone and often ruined by constant change and people who want to make things into other things they were never intended to be. I said something similar a few debates ago. I don't care what's popular as long as it still exists :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^ "As long as it still exists" is the critical connection to popularity here. It takes a certain minimum of interested people to keep it in existence. Despite being dramatically simpler than the alternatives, Modula-3 is still big enough that it needs several people to support it. We are really a bit low on this front. I can't seem to do the Modula-3 support I would like to do *and* use the language for my own projects too. And I'm retired. Frustrating. > > > > ------Original Message------ > From: Mika Nystrom > To: microcode at zoho.com > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Modula-3 questions > Sent: 19 Apr 2012 17:29 > > > But at the same time the Green Book (G. Nelson, ed., Systems Programming > with Modula-3, Prentice-Hall 1991) is probably the best description of > how to actually use object-oriented programming in practice that's ever > been published... > > I once wrote to whoever now owns Prentice-Hall and asked their copyright > clearance person for permission to photocopy chapters of that book > for a class I was teaching. No response, not even "absolutely not." > But most of it (all of it??) is available online. > > I'm somewhat ambivalent about marketing Modula-3 too hard. I fear that > if the hordes discover it, they will ruin it. One LONGINT is enough > headaches for me. I find the unchanging nature of the language to be > a huge advantage in what I do. > > Mika > > -----Original Message----- > From: microcode at zoho.com > Date: Thu, 19 Apr 2012 16:49:57 > To: Daniel Alejandro Benavides D. > Reply-To: microcode at zoho.com > Subject: Re: [M3devel] Modula-3 questions > > A big inhibitor to Modula-3 is the lack of books and tutorials. CM3 has a great system running on tons of platforms. But where can people learn to code Modula-3? > > I see this as the biggest obstacle. > > > > From dabenavidesd at yahoo.es Fri Apr 20 16:13:06 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 15:13:06 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> Message-ID: <1334931186.57202.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Well in terms of popularity we could stand for Modula-3 in search engines and see how much we got and how much we got from other for instance say Java. It might be that there are a number of good results in Modula-3, so I don't know much effort to do countability of that. But this is just to state preeminence. Later the popularity the number of times it has been searched that word (not so recent results for google were not bad at all). Whether the community is alive and kicking I would ask another question to elucidate that clearly; if industry has a better and strong feeling for Java and C++, than for Modula-3, and computers are becoming because of the non-turning point of 40 years of crisis almost a dead end where as any new computer comes becomes substantially slower, then, I would say that would live in that Universe of industrial-strength systems are not alive by those languages, but of very "dead" languages (say Modula-3 'died' in 2000 but not talking about communities, just languages), so some good inspiration came from older days and make that industry still making some money. Concerning about community is just one or two people apart from the industrial-strength systems is certainly better since it reflects the likely it would be survived by someone, and I happen to believe that languages in **critical** times are lead by just one or maybe two people, the rest are just followers. We might create a Modula-3 facebook or social network account and quickly realize that there are dozens of people interested and get their hands dirty in this crisis no more but in a good "dead" language, if somebody says that then the language is still alive in those followers I believe so. Thanks in advance --- El vie, 20/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Fw: Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: viernes, 20 de abril, 2012 08:48 > > > On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > > I haven't found that book or any Modula-3 books > online. > > > > I agree that things are often best left alone and often > ruined by constant change and people who > want to make things into other things they were never > intended to be. I said something similar a few > debates ago. I don't care what's popular > as long as it still exists :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > "As long as it still exists" is the critical connection to > popularity here. It takes a certain minimum > of interested people to keep it in existence. Despite > being dramatically simpler than the alternatives, > Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this > front. > > I can't seem to do the Modula-3 support I would like to do > *and* use the language for my own projects > too. And I'm retired. Frustrating. > > > > > > > > > > > ------Original Message------ > > From: Mika Nystrom > > To: microcode at zoho.com > > Cc: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: Modula-3 questions > > Sent: 19 Apr 2012 17:29 > > > > > > But at the same time the Green Book (G. Nelson, ed., > Systems Programming > > with Modula-3, Prentice-Hall 1991) is probably the best > description of > > how to actually use object-oriented programming in > practice that's ever > > been published... > > > > I once wrote to whoever now owns Prentice-Hall and > asked their copyright > > clearance person for permission to photocopy chapters > of that book > > for a class I was teaching. No response, not even > "absolutely not." > > But most of it (all of it??) is available online. > > > > I'm somewhat ambivalent about marketing Modula-3 too > hard. I fear that > > if the hordes discover it, they will ruin it. One > LONGINT is enough > > headaches for me. I find the unchanging nature of > the language to be > > a huge advantage in what I do. > > > > Mika > > > > -----Original Message----- > > From: microcode at zoho.com > > Date: Thu, 19 Apr 2012 16:49:57 > > To: Daniel Alejandro Benavides D. > > Reply-To: microcode at zoho.com > > Subject: Re: [M3devel] Modula-3 questions > > > > A big inhibitor to Modula-3 is the lack of books and > tutorials. CM3 has a great system running on tons of > platforms. But where can people learn to code Modula-3? > > > > I see this as the biggest obstacle. > > > > > > > > > From microcode at zoho.com Fri Apr 20 17:12:43 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Fri, 20 Apr 2012 15:12:43 +0000 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> Message-ID: <20120420160023.925D3DE925@mx0.elegosoft.com> On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > On 04/20/2012 04:12 AM, microcode at zoho.com wrote: >> I haven't found that book or any Modula-3 books online. >> >> I agree that things are often best left alone and often ruined by >> constant change and people who want to make things into other things >> they were never intended to be. I said something similar a few debates >> ago. I don't care what's popular as long as it still exists :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^ > "As long as it still exists" is the critical connection to popularity > here. It takes a certain minimum of interested people to keep it in > existence. Despite being dramatically simpler than the alternatives, > Modula-3 is still big enough that it needs several people to support it. > We are really a bit low on this front. I don't know what's involved but I don't think I can be much help with coding, unfortunately. I have offered to help out with systems support in the past and the offer still stands. I can host a couple of development systems for Solaris 10 SPARC and Intel on an as-requested basis if developers need them to keep CM3 going. I believe those platforms are already supported so I don't think I'm helping much here either but just in case. > I can't seem to do the Modula-3 support I would like to do *and* use the > language for my own projects too. And I'm retired. Frustrating. Sounds like good problems to have. I will try to install CM3 on Solaris in the next few weeks. I had it on Linux but my install didn't seem like it was working since most of the examples got errors trying to build. I'm also busy with work and home stuff blah blah blah. I have a lot of things going on and I don't get to most of what I would like to either. I feel your pain ;-) From dabenavidesd at yahoo.es Fri Apr 20 18:06:38 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 17:06:38 +0100 (BST) Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420023238.GE5407@topoi.pooq.com> Message-ID: <1334937998.62462.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: Interesting point but in original Modula [1], it was not that INTERFACE MODULEs were independent of, but monitors by them selves, and you could implement as you say, but later assumptions of that machines were not concurrent leave this concurrency out of the INTERFACEs. I believe that further developing that idea deserved more research than it's now, the concept of Objects as concurrent message sender receivers. Interestingly this the point of focus now on DDJ: http://www.drdobbs.com/parallel/232602463?cid=DDJ_nl_upd_2012-03-13_h&elq=be9ea13b9a534650b9e132e93de1931e The fact that the true roots of Modula's were in Mainframe machines if so, and before Object roots is appealing, o the idea is not original from them, though Some languages had featured Objects and messages before Small-talk way. So those machines were Module-oriented rather Object-oriented as some thought that is the leading architecture of new parallel systems [2] (p. 3). Thanks in advance [1] S. A. Williams, Programming models for parallel systems. J. Wiley, 1990. [2] R. Y. Kain, Computer architecture: software and hardware. Prentice Hall, 1989. --- El jue, 19/4/12, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] Modula-3 questions > Para: m3devel at elegosoft.com > Fecha: jueves, 19 de abril, 2012 21:32 > On Thu, Apr 19, 2012 at 05:30:36PM > +0100, Daniel Alejandro Benavides D. wrote: > > > > Modula-3 modularity is more uniform from that. > > The nice thing about Module 3's modularity is that it's > completely > independent of procedures, object types, global variables, > and all that. > You can use the language the way you want to, and still be > able to wrap > up whatever kind of module makes sense for your > application. > > -- hendrik > From penn43 at gmx.com Fri Apr 20 21:24:24 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:24:24 +0200 Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <4F91693E.9000903@lcwb.coop> References: <1329999034-1334913104-cardhu_decombobulator_blackberry.rim.net-493247593-@b1.c1.bise3.blackberry> <4F91693E.9000903@lcwb.coop> Message-ID: <20120420192424.27360@gmx.com> Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many language users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who need to maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh -------------- next part -------------- An HTML attachment was scrubbed... URL: From penn43 at gmx.com Fri Apr 20 21:30:25 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:30:25 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120420193025.27360@gmx.com> Sorry for double posting. I have just realized that my previous email was not visible (at least on Thunderbird), so I am posting it again here below. Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many Modula-3 users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who need to maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh From penn43 at gmx.com Fri Apr 20 21:37:17 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:37:17 +0200 Subject: [M3devel] Downsides of Modula-3 ? Message-ID: <20120420193717.27360@gmx.com> An object appraisal must take into account the problems too. So I am asking you, could you please mention any downsides of using Modula-3, in your experience? Of course, the non-existent language community has already been mentioned as a major downside. And the lack of documentation. What about other issues, such as compiler efficiency? Or interaction with foreign libraries? Thanks Marresh From penn43 at gmx.com Fri Apr 20 21:40:17 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:40:17 +0200 Subject: [M3devel] Downsides of Modula-3 ? Message-ID: <20120420194017.27360@gmx.com> > An object appraisal must take into account the problems too. So I am asking you, > could you please mention any downsides of using Modula-3, in your experience? Sorry, I meant to write "An objectIVE appraisal must..." From penn43 at gmx.com Fri Apr 20 21:45:08 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 21:45:08 +0200 Subject: [M3devel] Gtk2 binding Message-ID: <20120420194508.27350@gmx.com> > I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. Please, Dragi?a, could you share the binding with us? Thanks From dragisha at m3w.org Fri Apr 20 21:59:24 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 21:59:24 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <9553735C-579A-4564-BA89-66A42DEFE9E5@m3w.org> I don't see lack of documentation. On the contrary. Downside is - you are lone wolf. I am using a lot of foreign libraries and with C libs - no big problems. Last I used is/was libevent, and I made pretty complete OO binding around :). Efficiency of compiler, as well as ease of use is top notch. dd On Apr 20, 2012, at 9:37 PM, penn43 at gmx.com wrote: > An object appraisal must take into account the problems too. So I am asking you, could you please mention any downsides of using Modula-3, in your experience? > > Of course, the non-existent language community has already been mentioned as a major downside. > And the lack of documentation. > What about other issues, such as compiler efficiency? Or interaction with foreign libraries? > > Thanks > > Marresh From dragisha at m3w.org Fri Apr 20 22:00:33 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 22:00:33 +0200 Subject: [M3devel] Gtk2 binding In-Reply-To: <20120420194508.27350@gmx.com> References: <20120420194508.27350@gmx.com> Message-ID: <692013F4-7D06-497F-AD5C-0BA4EDCB3D62@m3w.org> If Rodney survives exposure :), I'll put a bit of effort into it and release it to public. dd On Apr 20, 2012, at 9:45 PM, penn43 at gmx.com wrote: > >> I did gtk2 binding and right now it's pretty useful. Right now I am working through gobject introspection with plans to automate complete bindings for everything gobject. Not shared at the moment, but no problem if anyone is interested. Currently, library is being developend and tested on LINUXLIBC6, AMD64_LINUX, AMD64_DARWIN and NT386. > > Please, Dragi?a, could you share the binding with us? > Thanks > From mika at async.caltech.edu Fri Apr 20 22:14:37 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 13:14:37 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420193025.27360@gmx.com> References: <20120420193025.27360@gmx.com> Message-ID: <20120420201437.5C6BB1A205B@async.async.caltech.edu> penn43 at gmx.com writes: ... > >BTW How many Modula-3 users are there? This info can serve as a "reality check >", to establish whether the language is dying or not. >Also, are there newcomers to the language? Or the only programmers who use it >are those who need to maintain legacy code? Most crucially, are any NEW progra >ms written in the language? >These are crucial questions to assess the situation in a more objective way. W >hat are your views on these points? > >To start with, could you hint to what kind of projects (new/legacy code) you u >se Modula-3 for? Would you use Modula-3 if you had to start writing the same p >rograms from scratch? > >Thanks > > >Marresh > Whenever I have the choice I write new code in Modula-3 or some system built on top of it. The main projects I've done recently have been a Verilog test bench generator written in Scheme (run on top of M3); an analysis program for financial forecasting (using some "serious" matrix math, e.g., Singular Value Decomposition); a circuit timing verifier written in a combination of Modula-3 and Scheme, incorporating everything from efficient parsers (in-place parsing using recursive descent) to a simple calculus and interval arithmetic package (in Scheme); a high-frequency stock trading program (data-to-order latencies around 50 microseconds). Most of these projects would have been much more laborious with any other tool I know of, or would have involved some serious performance tradeoffs. Mika From schlepptop at henning-thielemann.de Fri Apr 20 22:14:19 2012 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 20 Apr 2012 22:14:19 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <4F91C39B.8020307@henning-thielemann.de> penn43 at gmx.com schrieb: > What about other issues, such as compiler efficiency? Or interaction with foreign libraries? INLINE across module boundaries would be nice. From dragisha at m3w.org Fri Apr 20 22:28:25 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Apr 2012 22:28:25 +0200 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420201437.5C6BB1A205B@async.async.caltech.edu> References: <20120420193025.27360@gmx.com> <20120420201437.5C6BB1A205B@async.async.caltech.edu> Message-ID: <448D516D-FA8F-4D7F-8078-8198BC2A1B21@m3w.org> Same here. Lone wolf aspect :). With enough luck, you write Modula-3 all the time. On Apr 20, 2012, at 10:14 PM, Mika Nystrom wrote: > Whenever I have the choice I write new code in Modula-3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Apr 20 22:29:46 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 13:29:46 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420193717.27360@gmx.com> References: <20120420193717.27360@gmx.com> Message-ID: <20120420202946.0B35F1A205B@async.async.caltech.edu> Now that I have the rather unpleasant task of writing C code for a client, I have a few things I "like" about C and that I "miss" somewhat when I write Modula-3. I find that I sort of like the C preprocessor. But maybe it's just the sort of code I'm writing with it... (test programs, which need lots and lots of annotations and instrumentation, something easy to do with cpp). No alloca.... No varargs... No real "const" (Java "final"). Sometimes WITH can do it. No GO TO.............. can't believe I just wrote that but Modula-3 had as one of its design objectives to be a good target for code generation, and having goto would make that easier! (Look at the C-Mix partial evaluator for an application.) A C++ programmer would undoubtedly miss a lot of crazy C++ stuff that lets you do tricky stuff entirely without heap allocation. And operator overloading. Then there are some annoying implementation limitations: No EXTENDED floating point in the standard implementation. Bugs in the "standard" threading library (pthreads based). Have to use the longjmp hack version. Dubious "enhancements" relative to the Green Book: LONGINT, WIDECHAR (and a lot of issues with TEXT as a result). And efficiency problems in the CM3 code in *some cases* (compared with the older SRC M3). ---- My own evaluation of the above is that the things lacking relative to C are really pretty minor and the language is so much easier to use and better engineered that you almost never say to yourself "oh I wish I could write this procedure in C" (you might say it of one line of code). The implementation issues are things that could "easily" be fixed by someone who had the time.. Oh regarding efficiency problems: I still find that CM3 with optimization turned on produces code that runs faster and with a far smaller memory footprint than code doing the same thing in Java, most of the time. That's when you try to do as close to an apples-to-apples comparison as possible. If you take into account the fact that in Modula-3 you can allocate structured memory in "batches" (called "arrays"!) the difference is even bigger. Modula-3 also links far easier with C and Fortran than Java does. Mika penn43 at gmx.com writes: >An object appraisal must take into account the problems too. So I am asking yo >u, could you please mention any downsides of using Modula-3, in your experienc >e? > >Of course, the non-existent language community has already been mentioned as a > major downside. >And the lack of documentation. >What about other issues, such as compiler efficiency? Or interaction with fore >ign libraries? > >Thanks > >Marresh From penn43 at gmx.com Fri Apr 20 23:00:29 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Fri, 20 Apr 2012 23:00:29 +0200 Subject: [M3devel] Modula-3 questions Message-ID: <20120420210029.27340@gmx.com> > Same here. Lone wolf aspect Does the "lone wolf aspect" involve a lot of head-beating against the wall? Being a largely unsupported language, one may as well expect a lot of frustration. Honestly, how bad can it get? Any particularly problematic areas? Sorry if these nagging questions seem to you out of place. I am just trying to understand what I am getting into, if I decide to adopt Modula-3... Any real life experience greatly appreciated. From mika at async.caltech.edu Fri Apr 20 23:06:39 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Apr 2012 14:06:39 -0700 Subject: [M3devel] Modula-3 questions In-Reply-To: <20120420210029.27340@gmx.com> References: <20120420210029.27340@gmx.com> Message-ID: <20120420210639.D3F5A1A205B@async.async.caltech.edu> penn43 at gmx.com writes: >> Same here. Lone wolf aspect > >Does the "lone wolf aspect" involve a lot of head-beating against the wall? >Being a largely unsupported language, one may as well expect a lot of frustrat >ion. Honestly, how bad can it get? Any particularly problematic areas? People on this mailing list are very helpful, actually. Sometimes (see my previous email) the projects are a bit too big to tackle and those get left as restrictions. Serious user problems tend to happen with installation and if you care about some of the special things I mentioned in the last email. You generally don't need help with syntax (it's a simple language!) And if you want to learn "good style" I can highly recommend the Green Book's examples and some of the other libm3 code. If you need help with syntax it's generally with quake (the m3makefile language), not Modula-3 itself. In my experience this tends to happen when you want to do clever things with generics. Mika > >Sorry if these nagging questions seem to you out of place. I am just trying to > understand what I am getting into, if I decide to adopt Modula-3... Any real >life experience greatly appreciated. > From dabenavidesd at yahoo.es Fri Apr 20 23:30:31 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Apr 2012 22:30:31 +0100 (BST) Subject: [M3devel] Fw: Modula-3 questions In-Reply-To: <20120420192424.27360@gmx.com> Message-ID: <1334957431.79315.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: The question it's nor complete because if there are a dozen of programmers doing something that quicks on dead languages we don't know (the larger the space the easier you can't expect an answer ), but the Universe of alive programmers in the language is easier to respond. My objective view of this is that, English speakers should like Modula-3 for processing language matters, because that's the point of a language speaker to understand and process linguistically any language written in it for post process and the only one I know that mathematically adheres to its constructs (and not even Scala nor Java are perfectly sound) is but with some sort of verification capabilities is Modula-3. I arrive at this point after hearing a comment that shows the difference technically of C++ and Modula-3 and said "Modula-3 is created for being able to prove its constructs, which C++ it by itself is not". This? technologies resort to very expressive systems, which is what Modula-3 is about You can look at SRI - PARC for Pegasys project under direction by Mark Moriconi. Thanks in advance --- El vie, 20/4/12, penn43 at gmx.com escribi?: De: penn43 at gmx.com Asunto: Re: [M3devel] Fw: Modula-3 questions Para: m3devel at elegosoft.com Fecha: viernes, 20 de abril, 2012 14:24 Thank you all for your replies. >> I don't care what's popular as long as it still exists :-) > "As long as it still exists" is the critical connection to popularity here. It takes a certain > minimum of interested people to keep it in existence. Despite being dramatically simpler > than the alternatives, Modula-3 is still big enough that it needs several people to > support it. We are really a bit low on this front. BTW How many language users are there? This info can serve as a "reality check", to establish whether the language is dying or not. Also, are there newcomers to the language? Or the only programmers who use it are those who?need to?maintain legacy code? Most crucially, are any NEW programs written in the language? These are crucial questions to assess the situation in a more objective way. What are your views?on these points? To start with, could you hint to what kind of projects (new/legacy code) you use Modula-3 for? Would you use Modula-3 if you had to start writing the same programs from scratch? Thanks Marresh ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Sat Apr 21 00:09:32 2012 From: mark at wickensonline.co.uk (Mark Wickens) Date: Fri, 20 Apr 2012 23:09:32 +0100 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <20120420160023.925D3DE925@mx0.elegosoft.com> References: <20120420160023.925D3DE925@mx0.elegosoft.com> Message-ID: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Hi guys, I've been following this conversation with interest. I'd like to offer my opinion, although I'm not sure I'm qualified that much to offer one. So please humour me ;) I've been a contract and permanent software engineer for over a decade now. Although it is said that you should learn a new language every year, I'm guessing the definition of the word 'learn' depends on the amount of time and intellectual power you can apply. In my case, and I'm not sure I can completely use this as an excuse, I have small children so the amount of time I've got to do anything is limited. I recognise there are limitations to any language, and Java has quite a few. Some say it has become the COBOL of the modern age. From my perspective, whilst there may be limitations, when I have a generic software problem to solve (and always in a hurry) it's very difficult to justify invest the time and effort to explore alternatives. Having said that, during Retrochallenge I've managed to code in both C, Pascal and VAX Macro (VAX/VMS languages). I did plan to spend a month coding Modula-3. This is still on the cards for a future competition. I find it very difficult to categorise programming languages in terms of interest. Clearly languages like C, C++, Java, .NET etc. with their commercial heritage are taught at University to provide students with a foot through the door to finding their first job. I ought to qualify that I'm thinking here of general purpose languages rather than domain-specific languages, such as PHP. Other languages such as Scala and Erlang are designed to try and progress the ease with which multi-process/thread applications can be developed. Other more domain-specific languages such as Ruby are attempting to solve web-centric problems... Interestingly I searched for 'programming languages hot' in google and one of the languages listed in the Infoworld article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 was COBOL, but this is primarily listed because of commercial interests. Searching job adverts for programming languages definitely won't get you the full picture. So then we have languages for academic or personal interest. So where do we think that Modula-3 fits into this picture? One thing is for sure, it's not considered a 'hot' language, so I don't think you'll find many Universities teaching it now we're into 2010+ (please, please correct me if I'm wrong). To a certain extent the participants on this list are skewed - I would imagine you could work on the Modula-3 compiler given enough architecture knowledge without necessarily having a huge amount of Modula-3 development experience. So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? Then there are people who have developed projects in Modula-3 and found it a nice/useful/productive language to develop with. Having invested time in the language it would make sense to use the language. So an alternative way of promoting the language would be to publish applications on the internet. I haven't searched for this, but I suspect that there aren't many recent articles. I have lots of other thoughts about the matter, but would welcome comments... Regards, Mark. Sent from my iPad On 20 Apr 2012, at 16:12, microcode at zoho.com wrote: > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > >> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: >>> I haven't found that book or any Modula-3 books online. >>> >>> I agree that things are often best left alone and often ruined by >>> constant change and people who want to make things into other things >>> they were never intended to be. I said something similar a few debates >>> ago. I don't care what's popular as long as it still exists :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> "As long as it still exists" is the critical connection to popularity >> here. It takes a certain minimum of interested people to keep it in >> existence. Despite being dramatically simpler than the alternatives, >> Modula-3 is still big enough that it needs several people to support it. >> We are really a bit low on this front. > > I don't know what's involved but I don't think I can be much help with > coding, unfortunately. I have offered to help out with systems support in > the past and the offer still stands. I can host a couple of development > systems for Solaris 10 SPARC and Intel on an as-requested basis if > developers need them to keep CM3 going. I believe those platforms are > already supported so I don't think I'm helping much here either but just in > case. > > >> I can't seem to do the Modula-3 support I would like to do *and* use the >> language for my own projects too. And I'm retired. Frustrating. > > Sounds like good problems to have. I will try to install CM3 on Solaris in > the next few weeks. I had it on Linux but my install didn't seem like it > was working since most of the examples got errors trying to build. I'm also > busy with work and home stuff blah blah blah. I have a lot of things going > on and I don't get to most of what I would like to either. I feel your > pain ;-) > > > From dabenavidesd at yahoo.es Sat Apr 21 01:41:49 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 00:41:49 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <1334965309.33491.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: nice idea, but it didn't work earlier, what should I work on something that anybody can do by their-selves, one of the most interesting things of learning a new language environment, is that to certain degree you are a baby in that world if you dare, that's how I feel about Modula-3, I cannot guarantee that because as Greg Nelson said, "Modula-3 definition will perpetually incomplete" and computationally he was right but depending on the tool used for doing that affirmation. Thanks in advance PS Now, imagine if they dare to define a model of software based on any language, but just if it were Modula-3 or any "real" language, the rest is just the same thing over and over again, projects that never deserve any mention. --- El vie, 20/4/12, Mark Wickens escribi?: > De: Mark Wickens > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" > Fecha: viernes, 20 de abril, 2012 17:09 > Hi guys, > > I've been following this conversation with interest. I'd > like to offer my opinion, although I'm not sure I'm > qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for > over a decade now. Although it is said that you should learn > a new language every year, I'm guessing the definition of > the word 'learn' depends on the amount of time and > intellectual power you can apply. In my case, and I'm not > sure I can completely use this as an excuse, I have small > children so the amount of time I've got to do anything is > limited. > > I recognise there are limitations to any language, and Java > has quite a few. Some say it has become the COBOL of the > modern age. From my perspective, whilst there may be > limitations, when I have a generic software problem to solve > (and always in a hurry) it's very difficult to justify > invest the time and effort to explore alternatives. Having > said that, during Retrochallenge I've managed to code in > both C, Pascal and VAX Macro (VAX/VMS languages). I did plan > to spend a month coding Modula-3. This is still on the cards > for a future competition. > > I find it very difficult to categorise programming languages > in terms of interest. Clearly languages like C, C++, Java, > .NET etc. with their commercial heritage are taught at > University to provide students with a foot through the door > to finding their first job. I ought to qualify that I'm > thinking here of general purpose languages rather than > domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try > and progress the ease with which multi-process/thread > applications can be developed. Other more domain-specific > languages such as Ruby are attempting to solve web-centric > problems... > > Interestingly I searched for 'programming languages hot' in > google and one of the languages listed in the Infoworld > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > was COBOL, but this is primarily listed because of > commercial interests. Searching job adverts for programming > languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. > So where do we think that Modula-3 fits into this picture? > One thing is for sure, it's not considered a 'hot' language, > so I don't think you'll find many Universities teaching it > now we're into 2010+ (please, please correct me if I'm > wrong). > > To a certain extent the participants on this list are skewed > - I would imagine you could work on the Modula-3 compiler > given enough architecture knowledge without necessarily > having a huge amount of Modula-3 development experience. So > could development on the compiler be sold as a way of > gaining concrete skills in compiler development (IIRC it's > all developed in C)? > > Then there are people who have developed projects in > Modula-3 and found it a nice/useful/productive language to > develop with. Having invested time in the language it would > make sense to use the language. > > So an alternative way of promoting the language would be to > publish applications on the internet. > I haven't searched for this, but I suspect that there aren't > many recent articles. > > I have lots of other thoughts about the matter, but would > welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com > wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > >>> I haven't found that book or any Modula-3 books > online. > >>> > >>> I agree that things are often best left alone > and often ruined by > >>> constant change and people who want to make > things into other things > >>> they were never intended to be. I said > something similar a few debates > >>> ago. I don't care what's popular as long as it > still exists :-) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical > connection to popularity > >> here. It takes a certain minimum of > interested people to keep it in > >> existence. Despite being dramatically simpler > than the alternatives, > >> Modula-3 is still big enough that it needs several > people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be > much help with > > coding, unfortunately. I have offered to help out with > systems support in > > the past and the offer still stands. I can host a > couple of development > > systems for Solaris 10 SPARC and Intel on an > as-requested basis if > > developers need them to keep CM3 going. I believe those > platforms are > > already supported so I don't think I'm helping much > here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would > like to do *and* use the > >> language for my own projects too. And I'm > retired. Frustrating. > > > > Sounds like good problems to have. I will try to > install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install > didn't seem like it > > was working since most of the examples got errors > trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a > lot of things going > > on and I don't get to most of what I would like to > either. I feel your > > pain ;-) > > > > > > > From dabenavidesd at yahoo.es Sat Apr 21 03:30:42 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 02:30:42 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <1334965309.33491.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <1334971842.99402.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: the last phrase taken from here: http://books.google.com.co/books?id=M3F-lhug50cC&lpg=PP1&pg=PA137#v=onepage&q&f=false and before that [1] (I clarify further real-world languages doesn't include neither Oberon or its relative cousin Java, nor Smalltalk, so this is easier to proof literally) [1] I. A. and E. S. Society, COMPASS ?94: proceedings of the Ninth Annual Conference on Computer Assurance?: June 27-July 1, 1994, National Institute of Standards and Technology, Gaithersburg, MD?: safety, reliability, fault tolerance, concurrency and real time security. Institute of Electrical and Electronics Engineers, 1994. --- El vie, 20/4/12, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" , "Mark Wickens" > Fecha: viernes, 20 de abril, 2012 18:41 > Hi all: > nice idea, but it didn't work earlier, what should I work on > something that anybody can do by their-selves, one of > the most interesting things of learning a new language > environment, is that to certain degree you are a baby in > that world if you dare, that's how I feel about Modula-3, I > cannot guarantee that because as Greg Nelson said, "Modula-3 > definition will perpetually incomplete" and computationally > he was right but depending on the tool used for doing that > affirmation. > Thanks in advance > > PS Now, imagine if they dare to define a model of software > based on any language, but just if it were Modula-3 or any > "real" language, the rest is just the same thing over and > over again, projects that never deserve any mention. > > --- El vie, 20/4/12, Mark Wickens > escribi?: > > > De: Mark Wickens > > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 > questions > > Para: "m3devel at elegosoft.com" > > > Fecha: viernes, 20 de abril, 2012 17:09 > > Hi guys, > > > > I've been following this conversation with interest. > I'd > > like to offer my opinion, although I'm not sure I'm > > qualified that much to offer one. So please humour me > ;) > > > > I've been a contract and permanent software engineer > for > > over a decade now. Although it is said that you should > learn > > a new language every year, I'm guessing the definition > of > > the word 'learn' depends on the amount of time and > > intellectual power you can apply. In my case, and I'm > not > > sure I can completely use this as an excuse, I have > small > > children so the amount of time I've got to do anything > is > > limited. > > > > I recognise there are limitations to any language, and > Java > > has quite a few. Some say it has become the COBOL of > the > > modern age. From my perspective, whilst there may be > > limitations, when I have a generic software problem to > solve > > (and always in a hurry) it's very difficult to justify > > invest the time and effort to explore alternatives. > Having > > said that, during Retrochallenge I've managed to code > in > > both C, Pascal and VAX Macro (VAX/VMS languages). I did > plan > > to spend a month coding Modula-3. This is still on the > cards > > for a future competition. > > > > I find it very difficult to categorise programming > languages > > in terms of interest. Clearly languages like C, C++, > Java, > > .NET etc. with their commercial heritage are taught at > > University to provide students with a foot through the > door > > to finding their first job. I ought to qualify that > I'm > > thinking here of general purpose languages rather than > > domain-specific languages, such as PHP. > > > > Other languages such as Scala and Erlang are designed > to try > > and progress the ease with which multi-process/thread > > applications can be developed. Other more > domain-specific > > languages such as Ruby are attempting to solve > web-centric > > problems... > > > > Interestingly I searched for 'programming languages > hot' in > > google and one of the languages listed in the > Infoworld > > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > > was COBOL, but this is primarily listed because of > > commercial interests. Searching job adverts for > programming > > languages definitely won't get you the full picture. > > > > So then we have languages for academic or personal > interest. > > So where do we think that Modula-3 fits into this > picture? > > One thing is for sure, it's not considered a 'hot' > language, > > so I don't think you'll find many Universities teaching > it > > now we're into 2010+ (please, please correct me if I'm > > wrong). > > > > To a certain extent the participants on this list are > skewed > > - I would imagine you could work on the Modula-3 > compiler > > given enough architecture knowledge without > necessarily > > having a huge amount of Modula-3 development > experience. So > > could development on the compiler be sold as a way of > > gaining concrete skills in compiler development (IIRC > it's > > all developed in C)? > > > > Then there are people who have developed projects in > > Modula-3 and found it a nice/useful/productive language > to > > develop with. Having invested time in the language it > would > > make sense to use the language. > > > > So an alternative way of promoting the language would > be to > > publish applications on the internet. > > I haven't searched for this, but I suspect that there > aren't > > many recent articles. > > > > I have lots of other thoughts about the matter, but > would > > welcome comments... > > > > Regards, Mark. > > > > Sent from my iPad > > > > On 20 Apr 2012, at 16:12, microcode at zoho.com > > wrote: > > > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > > wrote > > > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > > wrote: > > >>> I haven't found that book or any Modula-3 > books > > online. > > >>> > > >>> I agree that things are often best left > alone > > and often ruined by > > >>> constant change and people who want to > make > > things into other things > > >>> they were never intended to be. I said > > something similar a few debates > > >>> ago. I don't care what's popular as long > as it > > still exists :-) > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > >> "As long as it still exists" is the critical > > connection to popularity > > >> here. It takes a certain minimum of > > interested people to keep it in > > >> existence. Despite being dramatically > simpler > > than the alternatives, > > >> Modula-3 is still big enough that it needs > several > > people to support it. > > >> We are really a bit low on this front. > > > > > > I don't know what's involved but I don't think I > can be > > much help with > > > coding, unfortunately. I have offered to help out > with > > systems support in > > > the past and the offer still stands. I can host a > > couple of development > > > systems for Solaris 10 SPARC and Intel on an > > as-requested basis if > > > developers need them to keep CM3 going. I believe > those > > platforms are > > > already supported so I don't think I'm helping > much > > here either but just in > > > case. > > > > > > > > >> I can't seem to do the Modula-3 support I > would > > like to do *and* use the > > >> language for my own projects too. And > I'm > > retired. Frustrating. > > > > > > Sounds like good problems to have. I will try to > > install CM3 on Solaris in > > > the next few weeks. I had it on Linux but my > install > > didn't seem like it > > > was working since most of the examples got errors > > trying to build. I'm also > > > busy with work and home stuff blah blah blah. I > have a > > lot of things going > > > on and I don't get to most of what I would like > to > > either. I feel your > > > pain ;-) > > > > > > > > > > > > From jay.krell at cornell.edu Sat Apr 21 05:33:01 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Apr 2012 03:33:01 +0000 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> References: <20120420160023.925D3DE925@mx0.elegosoft.com>, <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: > So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? This merits correction: The compile is largely written in Modula-3. It is broken up into a "builder", front end, other parts, and backends. The NT/x86 backend is written in Modula-3 and outputs .obj files directly. The "builder", front end, middle stuff, cross-module checking stuff (something related to "linking", depending on your point of view), NT/x86 backend are all linked into one executable -- cm3. The other backend is gcc. When using it cm3 outputs an intermediate form, that the gcc thing reads back in. The rest is written in Modula-3. - Jay > From: mark at wickensonline.co.uk > Date: Fri, 20 Apr 2012 23:09:32 +0100 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > > Hi guys, > > I've been following this conversation with interest. I'd like to offer my opinion, although I'm not sure I'm qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for over a decade now. Although it is said that you should learn a new language every year, I'm guessing the definition of the word 'learn' depends on the amount of time and intellectual power you can apply. In my case, and I'm not sure I can completely use this as an excuse, I have small children so the amount of time I've got to do anything is limited. > > I recognise there are limitations to any language, and Java has quite a few. Some say it has become the COBOL of the modern age. From my perspective, whilst there may be limitations, when I have a generic software problem to solve (and always in a hurry) it's very difficult to justify invest the time and effort to explore alternatives. Having said that, during Retrochallenge I've managed to code in both C, Pascal and VAX Macro (VAX/VMS languages). I did plan to spend a month coding Modula-3. This is still on the cards for a future competition. > > I find it very difficult to categorise programming languages in terms of interest. Clearly languages like C, C++, Java, .NET etc. with their commercial heritage are taught at University to provide students with a foot through the door to finding their first job. I ought to qualify that I'm thinking here of general purpose languages rather than domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try and progress the ease with which multi-process/thread applications can be developed. Other more domain-specific languages such as Ruby are attempting to solve web-centric problems... > > Interestingly I searched for 'programming languages hot' in google and one of the languages listed in the Infoworld article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 was COBOL, but this is primarily listed because of commercial interests. Searching job adverts for programming languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. So where do we think that Modula-3 fits into this picture? One thing is for sure, it's not considered a 'hot' language, so I don't think you'll find many Universities teaching it now we're into 2010+ (please, please correct me if I'm wrong). > > To a certain extent the participants on this list are skewed - I would imagine you could work on the Modula-3 compiler given enough architecture knowledge without necessarily having a huge amount of Modula-3 development experience. So could development on the compiler be sold as a way of gaining concrete skills in compiler development (IIRC it's all developed in C)? > > Then there are people who have developed projects in Modula-3 and found it a nice/useful/productive language to develop with. Having invested time in the language it would make sense to use the language. > > So an alternative way of promoting the language would be to publish applications on the internet. > I haven't searched for this, but I suspect that there aren't many recent articles. > > I have lots of other thoughts about the matter, but would welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com wrote: > >>> I haven't found that book or any Modula-3 books online. > >>> > >>> I agree that things are often best left alone and often ruined by > >>> constant change and people who want to make things into other things > >>> they were never intended to be. I said something similar a few debates > >>> ago. I don't care what's popular as long as it still exists :-) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical connection to popularity > >> here. It takes a certain minimum of interested people to keep it in > >> existence. Despite being dramatically simpler than the alternatives, > >> Modula-3 is still big enough that it needs several people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be much help with > > coding, unfortunately. I have offered to help out with systems support in > > the past and the offer still stands. I can host a couple of development > > systems for Solaris 10 SPARC and Intel on an as-requested basis if > > developers need them to keep CM3 going. I believe those platforms are > > already supported so I don't think I'm helping much here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would like to do *and* use the > >> language for my own projects too. And I'm retired. Frustrating. > > > > Sounds like good problems to have. I will try to install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install didn't seem like it > > was working since most of the examples got errors trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a lot of things going > > on and I don't get to most of what I would like to either. I feel your > > pain ;-) > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Sat Apr 21 08:43:22 2012 From: mark at wickensonline.co.uk (Mark Wickens) Date: Sat, 21 Apr 2012 07:43:22 +0100 Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: References: <20120420160023.925D3DE925@mx0.elegosoft.com>, <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <4F92570A.6090302@wickensonline.co.uk> On 21/04/12 04:33, Jay K wrote: > > So could development on the compiler be sold as a way of gaining > concrete skills in compiler development (IIRC it's all developed in C)? > > This merits correction: > The compile is largely written in Modula-3. > It is broken up into a "builder", front end, other parts, and backends. > The NT/x86 backend is written in Modula-3 and outputs .obj files > directly. > The "builder", front end, middle stuff, cross-module checking stuff > (something related to "linking", depending on your point of > view), NT/x86 backend are all linked into one executable -- cm3. > The other backend is gcc. When using it cm3 outputs an intermediate > form, that the gcc thing reads back in. > The rest is written in Modula-3. > Hi Jay, Thanks for the clarification. Having sent the email I did start to wonder whether I was correct in my statement... it's been a while since I looked at Modula-3! On an operational note I got a 'Certificate Not Trusted' error when attempting to access the roadmap https://projects.elego.de/cm3/roadmap. Regards, Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Apr 21 15:40:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 14:40:04 +0100 (BST) Subject: [M3devel] Subject: Re: Fw: Modula-3 questions In-Reply-To: <4D7CB835-D415-4F98-B7BA-0AED2939343F@wickensonline.co.uk> Message-ID: <1335015604.28434.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi Mark: if I'm not correct there please forgive but it is a possible answer to that picture you are trying to diagnose (specially maybe you can correct since you have known the VAX-RISC style machines of VAX9000 series if so), but I dare to believe that they put on those machines besides of VMS and Ultrix some sort of a Modula-3 OS because that was the only possible side for installing and running such a beasts smoothly. DEC abandoned the high needs application market because of marketing failures and misunderstandings (such as Parallelizing Fortran Compiler), but they have sold their right to market its super computer architecture designs to MasPar, and other computers are still supported in emulation companies and run in "Windows". Thanks in advance --- El vie, 20/4/12, Mark Wickens escribi?: > De: Mark Wickens > Asunto: Re: [M3devel] Subject: Re: Fw: Modula-3 questions > Para: "m3devel at elegosoft.com" > Fecha: viernes, 20 de abril, 2012 17:09 > Hi guys, > > I've been following this conversation with interest. I'd > like to offer my opinion, although I'm not sure I'm > qualified that much to offer one. So please humour me ;) > > I've been a contract and permanent software engineer for > over a decade now. Although it is said that you should learn > a new language every year, I'm guessing the definition of > the word 'learn' depends on the amount of time and > intellectual power you can apply. In my case, and I'm not > sure I can completely use this as an excuse, I have small > children so the amount of time I've got to do anything is > limited. > > I recognise there are limitations to any language, and Java > has quite a few. Some say it has become the COBOL of the > modern age. From my perspective, whilst there may be > limitations, when I have a generic software problem to solve > (and always in a hurry) it's very difficult to justify > invest the time and effort to explore alternatives. Having > said that, during Retrochallenge I've managed to code in > both C, Pascal and VAX Macro (VAX/VMS languages). I did plan > to spend a month coding Modula-3. This is still on the cards > for a future competition. > > I find it very difficult to categorise programming languages > in terms of interest. Clearly languages like C, C++, Java, > .NET etc. with their commercial heritage are taught at > University to provide students with a foot through the door > to finding their first job. I ought to qualify that I'm > thinking here of general purpose languages rather than > domain-specific languages, such as PHP. > > Other languages such as Scala and Erlang are designed to try > and progress the ease with which multi-process/thread > applications can be developed. Other more domain-specific > languages such as Ruby are attempting to solve web-centric > problems... > > Interestingly I searched for 'programming languages hot' in > google and one of the languages listed in the Infoworld > article http://www.infoworld.com/d/developer-world/7-programming-languages-the-rise-620?page=0,3 > was COBOL, but this is primarily listed because of > commercial interests. Searching job adverts for programming > languages definitely won't get you the full picture. > > So then we have languages for academic or personal interest. > So where do we think that Modula-3 fits into this picture? > One thing is for sure, it's not considered a 'hot' language, > so I don't think you'll find many Universities teaching it > now we're into 2010+ (please, please correct me if I'm > wrong). > > To a certain extent the participants on this list are skewed > - I would imagine you could work on the Modula-3 compiler > given enough architecture knowledge without necessarily > having a huge amount of Modula-3 development experience. So > could development on the compiler be sold as a way of > gaining concrete skills in compiler development (IIRC it's > all developed in C)? > > Then there are people who have developed projects in > Modula-3 and found it a nice/useful/productive language to > develop with. Having invested time in the language it would > make sense to use the language. > > So an alternative way of promoting the language would be to > publish applications on the internet. > I haven't searched for this, but I suspect that there aren't > many recent articles. > > I have lots of other thoughts about the matter, but would > welcome comments... > > Regards, Mark. > > Sent from my iPad > > On 20 Apr 2012, at 16:12, microcode at zoho.com > wrote: > > > On Fri Apr 20 14:47:49 2012 rodney_bates at lcwb.coop > wrote > > > >> On 04/20/2012 04:12 AM, microcode at zoho.com > wrote: > >>> I haven't found that book or any Modula-3 books > online. > >>> > >>> I agree that things are often best left alone > and often ruined by > >>> constant change and people who want to make > things into other things > >>> they were never intended to be. I said > something similar a few debates > >>> ago. I don't care what's popular as long as it > still exists :-) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> "As long as it still exists" is the critical > connection to popularity > >> here. It takes a certain minimum of > interested people to keep it in > >> existence. Despite being dramatically simpler > than the alternatives, > >> Modula-3 is still big enough that it needs several > people to support it. > >> We are really a bit low on this front. > > > > I don't know what's involved but I don't think I can be > much help with > > coding, unfortunately. I have offered to help out with > systems support in > > the past and the offer still stands. I can host a > couple of development > > systems for Solaris 10 SPARC and Intel on an > as-requested basis if > > developers need them to keep CM3 going. I believe those > platforms are > > already supported so I don't think I'm helping much > here either but just in > > case. > > > > > >> I can't seem to do the Modula-3 support I would > like to do *and* use the > >> language for my own projects too. And I'm > retired. Frustrating. > > > > Sounds like good problems to have. I will try to > install CM3 on Solaris in > > the next few weeks. I had it on Linux but my install > didn't seem like it > > was working since most of the examples got errors > trying to build. I'm also > > busy with work and home stuff blah blah blah. I have a > lot of things going > > on and I don't get to most of what I would like to > either. I feel your > > pain ;-) > > > > > > > From dabenavidesd at yahoo.es Sat Apr 21 18:26:48 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 21 Apr 2012 17:26:48 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120420202946.0B35F1A205B@async.async.caltech.edu> Message-ID: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. Thanks in advance --- El vie, 20/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: penn43 at gmx.com > CC: m3devel at elegosoft.com > Fecha: viernes, 20 de abril, 2012 15:29 > > Now that I have the rather unpleasant task of writing C code > for a client, > I have a few things I "like" about C and that I "miss" > somewhat when > I write Modula-3. > > I find that I sort of like the C preprocessor. But > maybe it's just the > sort of code I'm writing with it... (test programs, which > need lots and > lots of annotations and instrumentation, something easy to > do with cpp). > > No alloca.... > > No varargs... > > No real "const" (Java "final"). Sometimes WITH can do > it. > > No GO TO.............. can't believe I just wrote that but > Modula-3 had > as one of its design objectives to be a good target for code > generation, > and having goto would make that easier! (Look at the > C-Mix partial > evaluator for an application.) > > A C++ programmer would undoubtedly miss a lot of crazy C++ > stuff > that lets you do tricky stuff entirely without heap > allocation. > And operator overloading. > > Then there are some annoying implementation limitations: > > No EXTENDED floating point in the standard implementation. > > Bugs in the "standard" threading library (pthreads > based). Have > to use the longjmp hack version. > > Dubious "enhancements" relative to the Green Book: LONGINT, > WIDECHAR > (and a lot of issues with TEXT as a result). And > efficiency problems > in the CM3 code in *some cases* (compared with the older SRC > M3). > > ---- > > My own evaluation of the above is that the things lacking > relative to C > are really pretty minor and the language is so much easier > to use > and better engineered that you almost never say to yourself > "oh I wish > I could write this procedure in C" (you might say it of one > line of code). > > The implementation issues are things that could "easily" be > fixed by > someone who had the time.. > > Oh regarding efficiency problems: I still find that CM3 with > optimization > turned on produces code that runs faster and with a far > smaller memory > footprint than code doing the same thing in Java, most of > the time. > That's when you try to do as close to an apples-to-apples > comparison > as possible. If you take into account the fact that in > Modula-3 you can > allocate structured memory in "batches" (called "arrays"!) > the difference > is even bigger. Modula-3 also links far easier with C > and Fortran than > Java does. > > Mika > > > > penn43 at gmx.com > writes: > >An object appraisal must take into account the problems > too. So I am asking yo > >u, could you please mention any downsides of using > Modula-3, in your experienc > >e? > > > >Of course, the non-existent language community has > already been mentioned as a > > major downside. > >And the lack of documentation. > >What about other issues, such as compiler efficiency? Or > interaction with fore > >ign libraries? > > > >Thanks > > > >Marresh > From dknoto at next.com.pl Sat Apr 21 20:26:03 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Sat, 21 Apr 2012 20:26:03 +0200 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: References: <1328219233.94197.YahooMailClassic@web29702.mail.ird.yahoo.com> <1328220777.53225.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: <20120421202603.6ed1896b@wenus.next.com.pl> Dnia 2012-02-03, o godz. 16:13:55 Jay K napisa?(a): I finally found some time on the second approach to compile CM3 from source. I have got latest source from 2012/04/13. > Darious, how about cm3 -commands -keep? These options have not tried. > This sort of error indicates either the wrong cm3cg is being run or it is > being passed the wrong file, like mixing up .ic and .io files or somesuch. > Try adding -v to the cm3cg commands. You'll have to cd to the target > directory as well (AMD64_LINUX). > > I added option "-v" to the command "./do-cm3-core.sh -v buildship" and got the following result: >>> ... === package /home/dknoto/Oprogramowanie/Modula-3/Source/m3-libs/m3core === +++ cm3 -build -DROOT='/home/dknoto/Oprogramowanie/Modula-3/Source' $RARGS && cm3 -ship $RARGS -DROOT='/home/dknoto/Oprogramowanie/Modula-3/Source' +++ EVAL ("/usr/local/cm3/bin/cm3.cfg") --- building in AMD64_LINUX --- cd AMD64_LINUX ignoring ../src/m3overrides EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES inhale libm3core.m3x checking RTBuiltin.mx reading "../src/runtime/common/RTBuiltin.mx": 0 seconds checking RTHooks.i3 new source -> compiling RTHooks.i3 m3front ../src/runtime/common/RTHooks.i3 -w1 /home/dknoto/Oprogramowanie/Modula-3/Source/m3-sys/m3cc/AMD64_LINUX/gcc/m3cgc1 -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks RTHooks .ic -o RTHooks.is m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. m3_backend => 1 m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic rm RTHooks.is rm RTHooks.ic rm RTHooks.is checking RTHooks.m3 checking RuntimeError.i3 checking RT0.i3 <<< In directory m3-libs/m3core/AMD64_LINUX I have not file libm3core.so.5, but I have files *.o and file libm3core.m3x. I added the full building log to the attachment. Best regards Dariusz Knoci?ski. -------------- next part -------------- A non-text attachment was scrubbed... Name: buildship-2012-04-21_19-57.log.xz Type: application/x-xz Size: 23528 bytes Desc: not available URL: From dragisha at m3w.org Sat Apr 21 23:28:15 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 21 Apr 2012 23:28:15 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: What would be LONGADDRESS? Pointer to a location inside LONGRAM? :) On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? > Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. > Thanks in advance > > --- El vie, 20/4/12, Mika Nystrom escribi?: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: penn43 at gmx.com >> CC: m3devel at elegosoft.com >> Fecha: viernes, 20 de abril, 2012 15:29 >> >> Now that I have the rather unpleasant task of writing C code >> for a client, >> I have a few things I "like" about C and that I "miss" >> somewhat when >> I write Modula-3. >> >> I find that I sort of like the C preprocessor. But >> maybe it's just the >> sort of code I'm writing with it... (test programs, which >> need lots and >> lots of annotations and instrumentation, something easy to >> do with cpp). >> >> No alloca.... >> >> No varargs... >> >> No real "const" (Java "final"). Sometimes WITH can do >> it. >> >> No GO TO.............. can't believe I just wrote that but >> Modula-3 had >> as one of its design objectives to be a good target for code >> generation, >> and having goto would make that easier! (Look at the >> C-Mix partial >> evaluator for an application.) >> >> A C++ programmer would undoubtedly miss a lot of crazy C++ >> stuff >> that lets you do tricky stuff entirely without heap >> allocation. >> And operator overloading. >> >> Then there are some annoying implementation limitations: >> >> No EXTENDED floating point in the standard implementation. >> >> Bugs in the "standard" threading library (pthreads >> based). Have >> to use the longjmp hack version. >> >> Dubious "enhancements" relative to the Green Book: LONGINT, >> WIDECHAR >> (and a lot of issues with TEXT as a result). And >> efficiency problems >> in the CM3 code in *some cases* (compared with the older SRC >> M3). >> >> ---- >> >> My own evaluation of the above is that the things lacking >> relative to C >> are really pretty minor and the language is so much easier >> to use >> and better engineered that you almost never say to yourself >> "oh I wish >> I could write this procedure in C" (you might say it of one >> line of code). >> >> The implementation issues are things that could "easily" be >> fixed by >> someone who had the time.. >> >> Oh regarding efficiency problems: I still find that CM3 with >> optimization >> turned on produces code that runs faster and with a far >> smaller memory >> footprint than code doing the same thing in Java, most of >> the time. >> That's when you try to do as close to an apples-to-apples >> comparison >> as possible. If you take into account the fact that in >> Modula-3 you can >> allocate structured memory in "batches" (called "arrays"!) >> the difference >> is even bigger. Modula-3 also links far easier with C >> and Fortran than >> Java does. >> >> Mika >> >> >> >> penn43 at gmx.com >> writes: >>> An object appraisal must take into account the problems >> too. So I am asking yo >>> u, could you please mention any downsides of using >> Modula-3, in your experienc >>> e? >>> >>> Of course, the non-existent language community has >> already been mentioned as a >>> major downside. >>> And the lack of documentation. >>> What about other issues, such as compiler efficiency? Or >> interaction with fore >>> ign libraries? >>> >>> Thanks >>> >>> Marresh >> From jay.krell at cornell.edu Sun Apr 22 01:22:37 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Apr 2012 23:22:37 +0000 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com>, Message-ID: I don't understand what LONGADDRESS is either. > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. 1) please elaborate 2) We don't use longjmp as much any more, but get/set/make/swapcontext on platforms that support them.And where we do use longjmp, we have a more portable use than before -- we no longer hack on the jmpbuf.There is a "trick" where you use sigsetstack or some such to get the stack pointer into the jmpbuf.Look at the code and read the paper referenced. It is possible it didn't work on all platforms. But anyway, see #1.We'd really prefer to just use pthreads.Hm. I'd like to look again at what pthreads features we use -- I suspect pthreads/Win32 can beabstracted more thinly and the Modula-3 code less-forked/more-shared. But later.. - Jay > From: dragisha at m3w.org > Date: Sat, 21 Apr 2012 23:28:15 +0200 > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Downsides of Modula-3 ? > > What would be LONGADDRESS? Pointer to a location inside LONGRAM? :) > > On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you? > > Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well. > > Thanks in advance > > > > --- El vie, 20/4/12, Mika Nystrom escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: penn43 at gmx.com > >> CC: m3devel at elegosoft.com > >> Fecha: viernes, 20 de abril, 2012 15:29 > >> > >> Now that I have the rather unpleasant task of writing C code > >> for a client, > >> I have a few things I "like" about C and that I "miss" > >> somewhat when > >> I write Modula-3. > >> > >> I find that I sort of like the C preprocessor. But > >> maybe it's just the > >> sort of code I'm writing with it... (test programs, which > >> need lots and > >> lots of annotations and instrumentation, something easy to > >> do with cpp). > >> > >> No alloca.... > >> > >> No varargs... > >> > >> No real "const" (Java "final"). Sometimes WITH can do > >> it. > >> > >> No GO TO.............. can't believe I just wrote that but > >> Modula-3 had > >> as one of its design objectives to be a good target for code > >> generation, > >> and having goto would make that easier! (Look at the > >> C-Mix partial > >> evaluator for an application.) > >> > >> A C++ programmer would undoubtedly miss a lot of crazy C++ > >> stuff > >> that lets you do tricky stuff entirely without heap > >> allocation. > >> And operator overloading. > >> > >> Then there are some annoying implementation limitations: > >> > >> No EXTENDED floating point in the standard implementation. > >> > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. > >> > >> Dubious "enhancements" relative to the Green Book: LONGINT, > >> WIDECHAR > >> (and a lot of issues with TEXT as a result). And > >> efficiency problems > >> in the CM3 code in *some cases* (compared with the older SRC > >> M3). > >> > >> ---- > >> > >> My own evaluation of the above is that the things lacking > >> relative to C > >> are really pretty minor and the language is so much easier > >> to use > >> and better engineered that you almost never say to yourself > >> "oh I wish > >> I could write this procedure in C" (you might say it of one > >> line of code). > >> > >> The implementation issues are things that could "easily" be > >> fixed by > >> someone who had the time.. > >> > >> Oh regarding efficiency problems: I still find that CM3 with > >> optimization > >> turned on produces code that runs faster and with a far > >> smaller memory > >> footprint than code doing the same thing in Java, most of > >> the time. > >> That's when you try to do as close to an apples-to-apples > >> comparison > >> as possible. If you take into account the fact that in > >> Modula-3 you can > >> allocate structured memory in "batches" (called "arrays"!) > >> the difference > >> is even bigger. Modula-3 also links far easier with C > >> and Fortran than > >> Java does. > >> > >> Mika > >> > >> > >> > >> penn43 at gmx.com > >> writes: > >>> An object appraisal must take into account the problems > >> too. So I am asking yo > >>> u, could you please mention any downsides of using > >> Modula-3, in your experienc > >>> e? > >>> > >>> Of course, the non-existent language community has > >> already been mentioned as a > >>> major downside. > >>> And the lack of documentation. > >>> What about other issues, such as compiler efficiency? Or > >> interaction with fore > >>> ign libraries? > >>> > >>> Thanks > >>> > >>> Marresh > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 22 01:36:10 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 21 Apr 2012 16:36:10 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335025608.76948.YahooMailClassic@web29701.mail.ird.yahoo.com>, Message-ID: <20120421233610.B48281A205B@async.async.caltech.edu> Jay K writes: >1) please elaborate >2) We don't use longjmp as much any more=2C but get/set= >/make/swapcontext on platforms that support them.And where we do use longjm= >p=2C we have a more portable use than before -- we no longer hack on the jm= >pbuf.There is a "trick" where you use sigsetstack or some such to get the s= >tack pointer into the jmpbuf.Look at the code and read the paper referenced= >. It is possible it didn't work on all platforms. But anyway=2C see #1.We'= >d really prefer to just use pthreads.Hm. I'd like to look again at what pth= >reads features we use -- I suspect pthreads/Win32 can beabstracted more thi= >nly and the Modula-3 code less-forked/more-shared. But later.. - Jay > Fro= Sorry for the bad quote. My mailer still lives in the 7-bit world. In any case I was just mentioning as a problem with the current Modula-3 implementation that the pthreads bindings are buggy. I would not (and do not) use them for serious work. And user threads are, as we all know, not ideal... Anybody who wants to investigate the matter can start by running the thread testing program in m3core/tests/thread ... Main.m3 is fairly well documented. Mika From dabenavidesd at yahoo.es Sun Apr 22 18:41:28 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 17:41:28 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120421233610.B48281A205B@async.async.caltech.edu> Message-ID: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I'm more suspicious about the back needs over this programs, since Win32 programs have worked OK, have they? So I agree with you it's a matter of target implementation (not UNSAFE world), but that's in m3gcc backend, isn't it? Similarly your code could be fixed to uniprocessor semantics, so if this tests are OK either pthreads or embedded M3 threads this is a clear symptom of that UP semantics issue. In any case don't expect too many threads to do that correctly, since any exception in them can't be managed by Modula-3 RT (by language definition) but at most in m3gcc semantics I believe so. DECthreads had a nice mechanism to wrap it to Modula-3 style semantics so it could be easier to offer that in a internal CM3 API. Thanks in advance --- El s?b, 21/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Jay K" > CC: m3devel at elegosoft.com > Fecha: s?bado, 21 de abril, 2012 18:36 > Jay K writes: > >1) please elaborate > > >2) We don't use longjmp as much any more=2C but > get/set= > >/make/swapcontext on platforms that support them.And > where we do use longjm= > >p=2C we have a more portable use than before -- we no > longer hack on the jm= > >pbuf.There is a "trick" where you use sigsetstack or > some such to get the s= > >tack pointer into the jmpbuf.Look at the code and read > the paper referenced= > >. It is possible it didn't work on all platforms. > But anyway=2C see #1.We'= > >d really prefer to just use pthreads.Hm. I'd like to > look again at what pth= > >reads features we use -- I suspect pthreads/Win32 can > beabstracted more thi= > >nly and the Modula-3 code less-forked/more-shared. But > later.. - Jay > Fro= > > Sorry for the bad quote. My mailer still lives in the > 7-bit world. > > In any case I was just mentioning as a problem with the > current Modula-3 > implementation that the pthreads bindings are buggy. I > would not (and > do not) use them for serious work. And user threads > are, as we all know, > not ideal... > > Anybody who wants to investigate the matter can start by > running the thread > testing program in m3core/tests/thread ... Main.m3 is > fairly well documented. > > Mika > From dabenavidesd at yahoo.es Sun Apr 22 19:18:46 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 18:18:46 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: Message-ID: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space. Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit. Then the question what it would be like AMD64. Thanks in advance --- El s?b, 21/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com > Fecha: s?bado, 21 de abril, 2012 16:28 > What would be LONGADDRESS? Pointer to > a location inside LONGRAM? :) > > On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > If we accept to exist LONGINT and ADDRESS is a Word.T > why we don't have LONGADDRESS? That's you don't care if > that's in UNSAFE TYPE, do you? > > Assembly in lining was handled about perfect in > Modula-2 for VMS I wonder why DEC didn't provide Modula-3 > support with that as well. > > Thanks in advance > > > > --- El vie, 20/4/12, Mika Nystrom > escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: penn43 at gmx.com > >> CC: m3devel at elegosoft.com > >> Fecha: viernes, 20 de abril, 2012 15:29 > >> > >> Now that I have the rather unpleasant task of > writing C code > >> for a client, > >> I have a few things I "like" about C and that I > "miss" > >> somewhat when > >> I write Modula-3. > >> > >> I find that I sort of like the C > preprocessor. But > >> maybe it's just the > >> sort of code I'm writing with it... (test programs, > which > >> need lots and > >> lots of annotations and instrumentation, something > easy to > >> do with cpp). > >> > >> No alloca.... > >> > >> No varargs... > >> > >> No real "const" (Java "final"). Sometimes > WITH can do > >> it. > >> > >> No GO TO.............. can't believe I just wrote > that but > >> Modula-3 had > >> as one of its design objectives to be a good target > for code > >> generation, > >> and having goto would make that easier! (Look > at the > >> C-Mix partial > >> evaluator for an application.) > >> > >> A C++ programmer would undoubtedly miss a lot of > crazy C++ > >> stuff > >> that lets you do tricky stuff entirely without > heap > >> allocation. > >> And operator overloading. > >> > >> Then there are some annoying implementation > limitations: > >> > >> No EXTENDED floating point in the standard > implementation. > >> > >> Bugs in the "standard" threading library (pthreads > >> based). Have > >> to use the longjmp hack version. > >> > >> Dubious "enhancements" relative to the Green Book: > LONGINT, > >> WIDECHAR > >> (and a lot of issues with TEXT as a result). > And > >> efficiency problems > >> in the CM3 code in *some cases* (compared with the > older SRC > >> M3). > >> > >> ---- > >> > >> My own evaluation of the above is that the things > lacking > >> relative to C > >> are really pretty minor and the language is so much > easier > >> to use > >> and better engineered that you almost never say to > yourself > >> "oh I wish > >> I could write this procedure in C" (you might say > it of one > >> line of code). > >> > >> The implementation issues are things that could > "easily" be > >> fixed by > >> someone who had the time.. > >> > >> Oh regarding efficiency problems: I still find that > CM3 with > >> optimization > >> turned on produces code that runs faster and with a > far > >> smaller memory > >> footprint than code doing the same thing in Java, > most of > >> the time. > >> That's when you try to do as close to an > apples-to-apples > >> comparison > >> as possible. If you take into account the > fact that in > >> Modula-3 you can > >> allocate structured memory in "batches" (called > "arrays"!) > >> the difference > >> is even bigger. Modula-3 also links far > easier with C > >> and Fortran than > >> Java does. > >> > >> Mika > >> > >> > >> > >> penn43 at gmx.com > >> writes: > >>> An object appraisal must take into account the > problems > >> too. So I am asking yo > >>> u, could you please mention any downsides of > using > >> Modula-3, in your experienc > >>> e? > >>> > >>> Of course, the non-existent language community > has > >> already been mentioned as a > >>> major downside. > >>> And the lack of documentation. > >>> What about other issues, such as compiler > efficiency? Or > >> interaction with fore > >>> ign libraries? > >>> > >>> Thanks > >>> > >>> Marresh > >> > > From mika at async.caltech.edu Sun Apr 22 19:30:34 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Apr 2012 10:30:34 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <20120422173034.8ED311A205B@async.async.caltech.edu> I'm almost certain the problem is somewhere in the pthreads implementation of M3 threads, which consists of a couple of files of C and M3 within m3core. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >I'm more suspicious about the back needs over this programs, since Win32 pr= >ograms have worked OK, have they? So I agree with you it's a matter of targ= >et implementation (not UNSAFE world), but that's in m3gcc backend, isn't it= >? >Similarly your code could be fixed to uniprocessor semantics, so if this te= >sts are OK either pthreads or embedded M3 threads this is a clear symptom o= >f that UP semantics issue. >In any case don't expect too many threads to do that correctly, since any e= >xception in them can't be managed by Modula-3 RT (by language definition) b= >ut at most in m3gcc semantics I believe so. DECthreads had a nice mechanism= > to wrap it to Modula-3 style semantics so it could be easier to offer that= > in a internal CM3 API. >Thanks in advance > > >--- El s=E1b, 21/4/12, Mika Nystrom escribi=F3: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Jay K" >> CC: m3devel at elegosoft.com >> Fecha: s=E1bado, 21 de abril, 2012 18:36 >> Jay K writes: >> >1) please elaborate=20 >>=20 >> >2) We don't use longjmp as much any more=3D2C but >> get/set=3D >> >/make/swapcontext on platforms that support them.And >> where we do use longjm=3D >> >p=3D2C we have a more portable use than before -- we no >> longer hack on the jm=3D >> >pbuf.There is a "trick" where you use sigsetstack or >> some such to get the s=3D >> >tack pointer into the jmpbuf.Look at the code and read >> the paper referenced=3D >> >. It is possible it didn't work on all platforms.=20 >> But anyway=3D2C see #1.We'=3D >> >d really prefer to just use pthreads.Hm. I'd like to >> look again at what pth=3D >> >reads features we use -- I suspect pthreads/Win32 can >> beabstracted more thi=3D >> >nly and the Modula-3 code less-forked/more-shared. But >> later.. - Jay > Fro=3D >>=20 >> Sorry for the bad quote. My mailer still lives in the >> 7-bit world. >>=20 >> In any case I was just mentioning as a problem with the >> current Modula-3 >> implementation that the pthreads bindings are buggy. I >> would not (and >> do not) use them for serious work. And user threads >> are, as we all know, >> not ideal... >>=20 >> Anybody who wants to investigate the matter can start by >> running the thread >> testing program in m3core/tests/thread ... Main.m3 is >> fairly well documented. >>=20 >> Mika >> From mika at async.caltech.edu Sun Apr 22 19:43:28 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Apr 2012 10:43:28 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <20120422174328.68DB81A205B@async.async.caltech.edu> But the thing is, if the produced code were thread unsafe, it likely wouldn't work with user threads either... I admit what you say is possible but it ought to be ruled out by the semantics of pthreads. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >Please this makes think that the current systems are a lottery, because the= >y don't mark thread-safe code (or they are all safe assumed as thread-unsaf= >e): >http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe > >Even if they compiler is not threaded by itself it can cause a back-end to = >be thread-unsafe, so that's why I say that it could be in that back-end. > >But then the code must be marked by each module and I think assuming all ar= >e thread-unsafe is correct to say. >Thanks in advance > >--- El dom, 22/4/12, Mika Nystrom escribi=F3: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Daniel Alejandro Benavides D." >> CC: m3devel at elegosoft.com >> Fecha: domingo, 22 de abril, 2012 12:30 >>=20 >> I'm almost certain the problem is somewhere in the pthreads >> implementation >> of M3 threads, which consists of a couple of files of C and >> M3 within >> m3core. >>=20 >> Mika >>=20 >> "Daniel Alejandro Benavides D." writes: >> >Hi all: >> >I'm more suspicious about the back needs over this >> programs, since Win32 pr=3D >> >ograms have worked OK, have they? So I agree with you >> it's a matter of targ=3D >> >et implementation (not UNSAFE world), but that's in >> m3gcc backend, isn't it=3D >> >? >> >Similarly your code could be fixed to uniprocessor >> semantics, so if this te=3D >> >sts are OK either pthreads or embedded M3 threads this >> is a clear symptom o=3D >> >f that UP semantics issue. >> >In any case don't expect too many threads to do that >> correctly, since any e=3D >> >xception in them can't be managed by Modula-3 RT (by >> language definition) b=3D >> >ut at most in m3gcc semantics I believe so. DECthreads >> had a nice mechanism=3D >> > to wrap it to Modula-3 style semantics so it could be >> easier to offer that=3D >> > in a internal CM3 API. >> >Thanks in advance >> > >> > >> >--- El s=3DE1b, 21/4/12, Mika Nystrom >> escribi=3DF3: >> > >> >> De: Mika Nystrom >> >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> >> Para: "Jay K" >> >> CC: m3devel at elegosoft.com >> >> Fecha: s=3DE1bado, 21 de abril, 2012 18:36 >> >> Jay K writes: >> >> >1) please elaborate=3D20 >> >>=3D20 >> >> >2) We don't use longjmp as much any more=3D3D2C >> but >> >> get/set=3D3D >> >> >/make/swapcontext on platforms that support >> them.And >> >> where we do use longjm=3D3D >> >> >p=3D3D2C we have a more portable use than before >> -- we no >> >> longer hack on the jm=3D3D >> >> >pbuf.There is a "trick" where you use >> sigsetstack or >> >> some such to get the s=3D3D >> >> >tack pointer into the jmpbuf.Look at the code >> and read >> >> the paper referenced=3D3D >> >> >. It is possible it didn't work on all >> platforms.=3D20 >> >> But anyway=3D3D2C see #1.We'=3D3D >> >> >d really prefer to just use pthreads.Hm. I'd >> like to >> >> look again at what pth=3D3D >> >> >reads features we use -- I suspect >> pthreads/Win32 can >> >> beabstracted more thi=3D3D >> >> >nly and the Modula-3 code >> less-forked/more-shared. But >> >> later.. - Jay > Fro=3D3D >> >>=3D20 >> >> Sorry for the bad quote. My mailer still >> lives in the >> >> 7-bit world. >> >>=3D20 >> >> In any case I was just mentioning as a problem with >> the >> >> current Modula-3 >> >> implementation that the pthreads bindings are >> buggy. I >> >> would not (and >> >> do not) use them for serious work. And user >> threads >> >> are, as we all know, >> >> not ideal... >> >>=3D20 >> >> Anybody who wants to investigate the matter can >> start by >> >> running the thread >> >> testing program in m3core/tests/thread ...=20 >> Main.m3 is >> >> fairly well documented. >> >>=3D20 >> >> Mika >> >>=20 >> From dabenavidesd at yahoo.es Sun Apr 22 19:40:31 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 18:40:31 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120422173034.8ED311A205B@async.async.caltech.edu> Message-ID: <1335116431.92358.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Please this makes think that the current systems are a lottery, because they don't mark thread-safe code (or they are all safe assumed as thread-unsafe): http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe Even if they compiler is not threaded by itself it can cause a back-end to be thread-unsafe, so that's why I say that it could be in that back-end. But then the code must be marked by each module and I think assuming all are thread-unsafe is correct to say. Thanks in advance --- El dom, 22/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 12:30 > > I'm almost certain the problem is somewhere in the pthreads > implementation > of M3 threads, which consists of a couple of files of C and > M3 within > m3core. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I'm more suspicious about the back needs over this > programs, since Win32 pr= > >ograms have worked OK, have they? So I agree with you > it's a matter of targ= > >et implementation (not UNSAFE world), but that's in > m3gcc backend, isn't it= > >? > >Similarly your code could be fixed to uniprocessor > semantics, so if this te= > >sts are OK either pthreads or embedded M3 threads this > is a clear symptom o= > >f that UP semantics issue. > >In any case don't expect too many threads to do that > correctly, since any e= > >xception in them can't be managed by Modula-3 RT (by > language definition) b= > >ut at most in m3gcc semantics I believe so. DECthreads > had a nice mechanism= > > to wrap it to Modula-3 style semantics so it could be > easier to offer that= > > in a internal CM3 API. > >Thanks in advance > > > > > >--- El s=E1b, 21/4/12, Mika Nystrom > escribi=F3: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Jay K" > >> CC: m3devel at elegosoft.com > >> Fecha: s=E1bado, 21 de abril, 2012 18:36 > >> Jay K writes: > >> >1) please elaborate=20 > >>=20 > >> >2) We don't use longjmp as much any more=3D2C > but > >> get/set=3D > >> >/make/swapcontext on platforms that support > them.And > >> where we do use longjm=3D > >> >p=3D2C we have a more portable use than before > -- we no > >> longer hack on the jm=3D > >> >pbuf.There is a "trick" where you use > sigsetstack or > >> some such to get the s=3D > >> >tack pointer into the jmpbuf.Look at the code > and read > >> the paper referenced=3D > >> >. It is possible it didn't work on all > platforms.=20 > >> But anyway=3D2C see #1.We'=3D > >> >d really prefer to just use pthreads.Hm. I'd > like to > >> look again at what pth=3D > >> >reads features we use -- I suspect > pthreads/Win32 can > >> beabstracted more thi=3D > >> >nly and the Modula-3 code > less-forked/more-shared. But > >> later.. - Jay > Fro=3D > >>=20 > >> Sorry for the bad quote. My mailer still > lives in the > >> 7-bit world. > >>=20 > >> In any case I was just mentioning as a problem with > the > >> current Modula-3 > >> implementation that the pthreads bindings are > buggy. I > >> would not (and > >> do not) use them for serious work. And user > threads > >> are, as we all know, > >> not ideal... > >>=20 > >> Anybody who wants to investigate the matter can > start by > >> running the thread > >> testing program in m3core/tests/thread ... > Main.m3 is > >> fairly well documented. > >>=20 > >> Mika > >> > From dabenavidesd at yahoo.es Sun Apr 22 20:01:21 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Apr 2012 19:01:21 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120422174328.68DB81A205B@async.async.caltech.edu> Message-ID: <1335117681.25789.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I agree too, but then that is assuming that you code is inherently thread-safe, which we don't care either or worse in Modula-e libraries BTW, we could have THREADSAFE or SAFE keyword of that and so ... Now, what Antony and someone once said, that "embedded" green threads are not that semantically correct assuming some things over them (for instance UP semantics), then we should make some primitives for handling the new implementation of threads just to be sure. Thanks in advance --- El dom, 22/4/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 12:43 > > But the thing is, if the produced code were thread unsafe, > it likely > wouldn't work with user threads either... > > I admit what you say is possible but it ought to be ruled > out by the > semantics of pthreads. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >Please this makes think that the current systems are a > lottery, because the= > >y don't mark thread-safe code (or they are all safe > assumed as thread-unsaf= > >e): > >http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe > > > >Even if they compiler is not threaded by itself it can > cause a back-end to = > >be thread-unsafe, so that's why I say that it could be > in that back-end. > > > >But then the code must be marked by each module and I > think assuming all ar= > >e thread-unsafe is correct to say. > >Thanks in advance > > > >--- El dom, 22/4/12, Mika Nystrom > escribi=F3: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Daniel Alejandro Benavides D." > >> CC: m3devel at elegosoft.com > >> Fecha: domingo, 22 de abril, 2012 12:30 > >>=20 > >> I'm almost certain the problem is somewhere in the > pthreads > >> implementation > >> of M3 threads, which consists of a couple of files > of C and > >> M3 within > >> m3core. > >>=20 > >> Mika > >>=20 > >> "Daniel Alejandro Benavides D." writes: > >> >Hi all: > >> >I'm more suspicious about the back needs over > this > >> programs, since Win32 pr=3D > >> >ograms have worked OK, have they? So I agree > with you > >> it's a matter of targ=3D > >> >et implementation (not UNSAFE world), but > that's in > >> m3gcc backend, isn't it=3D > >> >? > >> >Similarly your code could be fixed to > uniprocessor > >> semantics, so if this te=3D > >> >sts are OK either pthreads or embedded M3 > threads this > >> is a clear symptom o=3D > >> >f that UP semantics issue. > >> >In any case don't expect too many threads to do > that > >> correctly, since any e=3D > >> >xception in them can't be managed by Modula-3 > RT (by > >> language definition) b=3D > >> >ut at most in m3gcc semantics I believe so. > DECthreads > >> had a nice mechanism=3D > >> > to wrap it to Modula-3 style semantics so it > could be > >> easier to offer that=3D > >> > in a internal CM3 API. > >> >Thanks in advance > >> > > >> > > >> >--- El s=3DE1b, 21/4/12, Mika Nystrom > >> escribi=3DF3: > >> > > >> >> De: Mika Nystrom > >> >> Asunto: Re: [M3devel] Downsides of > Modula-3 ? > >> >> Para: "Jay K" > >> >> CC: m3devel at elegosoft.com > >> >> Fecha: s=3DE1bado, 21 de abril, 2012 > 18:36 > >> >> Jay K writes: > >> >> >1) please elaborate=3D20 > >> >>=3D20 > >> >> >2) We don't use longjmp as much any > more=3D3D2C > >> but > >> >> get/set=3D3D > >> >> >/make/swapcontext on platforms that > support > >> them.And > >> >> where we do use longjm=3D3D > >> >> >p=3D3D2C we have a more portable use > than before > >> -- we no > >> >> longer hack on the jm=3D3D > >> >> >pbuf.There is a "trick" where you use > >> sigsetstack or > >> >> some such to get the s=3D3D > >> >> >tack pointer into the jmpbuf.Look at > the code > >> and read > >> >> the paper referenced=3D3D > >> >> >. It is possible it didn't work on > all > >> platforms.=3D20 > >> >> But anyway=3D3D2C see #1.We'=3D3D > >> >> >d really prefer to just use > pthreads.Hm. I'd > >> like to > >> >> look again at what pth=3D3D > >> >> >reads features we use -- I suspect > >> pthreads/Win32 can > >> >> beabstracted more thi=3D3D > >> >> >nly and the Modula-3 code > >> less-forked/more-shared. But > >> >> later.. - Jay > Fro=3D3D > >> >>=3D20 > >> >> Sorry for the bad quote. My mailer > still > >> lives in the > >> >> 7-bit world. > >> >>=3D20 > >> >> In any case I was just mentioning as a > problem with > >> the > >> >> current Modula-3 > >> >> implementation that the pthreads bindings > are > >> buggy. I > >> >> would not (and > >> >> do not) use them for serious work. > And user > >> threads > >> >> are, as we all know, > >> >> not ideal... > >> >>=3D20 > >> >> Anybody who wants to investigate the > matter can > >> start by > >> >> running the thread > >> >> testing program in m3core/tests/thread > ...=20 > >> Main.m3 is > >> >> fairly well documented. > >> >>=3D20 > >> >> Mika > >> >>=20 > >> > From rodney_bates at lcwb.coop Sun Apr 22 20:43:07 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Apr 2012 13:43:07 -0500 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335112888.58120.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <4F94513B.3060802@lcwb.coop> On 04/22/2012 11:41 AM, Daniel Alejandro Benavides D. wrote: > Hi all: > I'm more suspicious about the back needs over this programs, since Win32 programs have worked OK, have they? So I agree with you it's a matter of target implementation (not UNSAFE world), but that's in m3gcc backend, isn't it? > Similarly your code could be fixed to uniprocessor semantics, so if this tests are OK either pthreads or embedded M3 threads this is a clear symptom of that UP semantics issue. > In any case don't expect too many threads to do that correctly, since any exception in them can't be managed by Modula-3 RT (by language definition) I'm not sure what you mean by this, but in my reading, the language definition fully defines the interaction between threads and exceptions. Exceptions can propagate only within a thread. All the rules about where they propagate are in terms of either a statically enclosing block or a dynamic parent, that is, the caller of the current procedure. In both cases, it's strictly within the thread where the exception was raised. If an exception ever got to the top of the call chain of its thread, it would have to be the result of an override of the apply method of the closure passed to Thread.Fork. But that method has an empty RAISES clause, so if that should happen, it would be a runtime error, still within the thread. but at most in m3gcc semantics I believe so. DECthreads had a nice mechanism to wrap it to Modula-3 style semantics so it could be easier to offer that in a internal CM3 API. > Thanks in advance > > > --- El s?b, 21/4/12, Mika Nystrom escribi?: > >> De: Mika Nystrom >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Jay K" >> CC: m3devel at elegosoft.com >> Fecha: s?bado, 21 de abril, 2012 18:36 >> Jay K writes: >>> 1) please elaborate >> >>> 2) We don't use longjmp as much any more=2C but >> get/set= >>> /make/swapcontext on platforms that support them.And >> where we do use longjm= >>> p=2C we have a more portable use than before -- we no >> longer hack on the jm= >>> pbuf.There is a "trick" where you use sigsetstack or >> some such to get the s= >>> tack pointer into the jmpbuf.Look at the code and read >> the paper referenced= >>> . It is possible it didn't work on all platforms. >> But anyway=2C see #1.We'= >>> d really prefer to just use pthreads.Hm. I'd like to >> look again at what pth= >>> reads features we use -- I suspect pthreads/Win32 can >> beabstracted more thi= >>> nly and the Modula-3 code less-forked/more-shared. But >> later.. - Jay> Fro= >> >> Sorry for the bad quote. My mailer still lives in the >> 7-bit world. >> >> In any case I was just mentioning as a problem with the >> current Modula-3 >> implementation that the pthreads bindings are buggy. I >> would not (and >> do not) use them for serious work. And user threads >> are, as we all know, >> not ideal... >> >> Anybody who wants to investigate the matter can start by >> running the thread >> testing program in m3core/tests/thread ... Main.m3 is >> fairly well documented. >> >> Mika >> > From dragisha at m3w.org Sun Apr 22 20:50:42 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 22 Apr 2012 20:50:42 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1335115126.32300.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: In other words, let's invent another non-portability :). Pass, please :) On Apr 22, 2012, at 7:18 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space. > Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit. > Then the question what it would be like AMD64. > Thanks in advance > > --- El s?b, 21/4/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: Re: [M3devel] Downsides of Modula-3 ? >> Para: "Daniel Alejandro Benavides D." >> CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com >> Fecha: s?bado, 21 de abril, 2012 16:28 >> What would be LONGADDRESS? Pointer to >> a location inside LONGRAM? :) >> >> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. >> wrote: >> >>> Hi all: >>> If we accept to exist LONGINT and ADDRESS is a Word.T >> why we don't have LONGADDRESS? That's you don't care if >> that's in UNSAFE TYPE, do you? >>> Assembly in lining was handled about perfect in >> Modula-2 for VMS I wonder why DEC didn't provide Modula-3 >> support with that as well. >>> Thanks in advance >>> >>> --- El vie, 20/4/12, Mika Nystrom >> escribi?: >>> >>>> De: Mika Nystrom >>>> Asunto: Re: [M3devel] Downsides of Modula-3 ? >>>> Para: penn43 at gmx.com >>>> CC: m3devel at elegosoft.com >>>> Fecha: viernes, 20 de abril, 2012 15:29 >>>> >>>> Now that I have the rather unpleasant task of >> writing C code >>>> for a client, >>>> I have a few things I "like" about C and that I >> "miss" >>>> somewhat when >>>> I write Modula-3. >>>> >>>> I find that I sort of like the C >> preprocessor. But >>>> maybe it's just the >>>> sort of code I'm writing with it... (test programs, >> which >>>> need lots and >>>> lots of annotations and instrumentation, something >> easy to >>>> do with cpp). >>>> >>>> No alloca.... >>>> >>>> No varargs... >>>> >>>> No real "const" (Java "final"). Sometimes >> WITH can do >>>> it. >>>> >>>> No GO TO.............. can't believe I just wrote >> that but >>>> Modula-3 had >>>> as one of its design objectives to be a good target >> for code >>>> generation, >>>> and having goto would make that easier! (Look >> at the >>>> C-Mix partial >>>> evaluator for an application.) >>>> >>>> A C++ programmer would undoubtedly miss a lot of >> crazy C++ >>>> stuff >>>> that lets you do tricky stuff entirely without >> heap >>>> allocation. >>>> And operator overloading. >>>> >>>> Then there are some annoying implementation >> limitations: >>>> >>>> No EXTENDED floating point in the standard >> implementation. >>>> >>>> Bugs in the "standard" threading library (pthreads >>>> based). Have >>>> to use the longjmp hack version. >>>> >>>> Dubious "enhancements" relative to the Green Book: >> LONGINT, >>>> WIDECHAR >>>> (and a lot of issues with TEXT as a result). >> And >>>> efficiency problems >>>> in the CM3 code in *some cases* (compared with the >> older SRC >>>> M3). >>>> >>>> ---- >>>> >>>> My own evaluation of the above is that the things >> lacking >>>> relative to C >>>> are really pretty minor and the language is so much >> easier >>>> to use >>>> and better engineered that you almost never say to >> yourself >>>> "oh I wish >>>> I could write this procedure in C" (you might say >> it of one >>>> line of code). >>>> >>>> The implementation issues are things that could >> "easily" be >>>> fixed by >>>> someone who had the time.. >>>> >>>> Oh regarding efficiency problems: I still find that >> CM3 with >>>> optimization >>>> turned on produces code that runs faster and with a >> far >>>> smaller memory >>>> footprint than code doing the same thing in Java, >> most of >>>> the time. >>>> That's when you try to do as close to an >> apples-to-apples >>>> comparison >>>> as possible. If you take into account the >> fact that in >>>> Modula-3 you can >>>> allocate structured memory in "batches" (called >> "arrays"!) >>>> the difference >>>> is even bigger. Modula-3 also links far >> easier with C >>>> and Fortran than >>>> Java does. >>>> >>>> Mika >>>> >>>> >>>> >>>> penn43 at gmx.com >>>> writes: >>>>> An object appraisal must take into account the >> problems >>>> too. So I am asking yo >>>>> u, could you please mention any downsides of >> using >>>> Modula-3, in your experienc >>>>> e? >>>>> >>>>> Of course, the non-existent language community >> has >>>> already been mentioned as a >>>>> major downside. >>>>> And the lack of documentation. >>>>> What about other issues, such as compiler >> efficiency? Or >>>> interaction with fore >>>>> ign libraries? >>>>> >>>>> Thanks >>>>> >>>>> Marresh >>>> >> >> From penn43 at gmx.com Mon Apr 23 16:30:06 2012 From: penn43 at gmx.com (penn43 at gmx.com) Date: Mon, 23 Apr 2012 16:30:06 +0200 Subject: [M3devel] Support for UTF-8 and email protocols Message-ID: <20120423143006.27340@gmx.com> Hi, sorry if I asked this question before, but it went unanswered and I really need to know. Are there available libraries that support: 1) UTF-8 text 2) email protocols (SMTP and POP3) -- I need client-side support ONLY. (These two functionalities are distinct, of course.) Thanks Marresh From dabenavidesd at yahoo.es Mon Apr 23 23:46:53 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Apr 2012 22:46:53 +0100 (BST) Subject: [M3devel] Support for UTF-8 and email protocols In-Reply-To: <20120423143006.27340@gmx.com> Message-ID: <1335217613.54933.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: Support of basics is there but there isn't too much in examples, etc. WIDECHAR type is the basic building block for your UTF support, but you need to be wise, somehow, it is still untested by most of us. Support for the protocol on that eagerly needs work, I don't any known free coded server system that is portable for truth, so I'd guess that unless somebody needed it, nobody has yet one client for Modula-3 or such. Instead there could be an approach but it's too much top-down using GenVoca coming from Avoca OS written in Modula-3 for writing network protocols. I hope it helps. Thanks in advance --- El lun, 23/4/12, penn43 at gmx.com escribi?: > De: penn43 at gmx.com > Asunto: [M3devel] Support for UTF-8 and email protocols > Para: m3devel at elegosoft.com > Fecha: lunes, 23 de abril, 2012 09:30 > Hi, > > sorry if I asked this question before, but it went > unanswered and I really need to know. > > Are there available libraries that support: > > 1) UTF-8 text > > 2) email protocols (SMTP and POP3) -- I need client-side > support ONLY. > > (These two functionalities are distinct, of course.) > > Thanks > > Marresh > > From dabenavidesd at yahoo.es Tue Apr 24 16:42:39 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 24 Apr 2012 15:42:39 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance --- El dom, 22/4/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: "Daniel Alejandro Benavides D." > CC: penn43 at gmx.com, "Mika Nystrom" , m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 13:50 > In other words, let's invent another > non-portability :). > > Pass, please :) > > On Apr 22, 2012, at 7:18 PM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > I think it would be in I386 (I remember were 16 bits) > and absolute address location of a Word.T were handled as > such in I386 process at least that's in my MSJ Vol. 7 No.4, > because it has Application Address Space and at top System > Address Space. > > Similarly in ARMv7the virtual address space is 32-bit, > but physically extended to be 40-bit. > > Then the question what it would be like AMD64. > > Thanks in advance > > > > --- El s?b, 21/4/12, Dragi?a Duri? > escribi?: > > > >> De: Dragi?a Duri? > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Daniel Alejandro Benavides D." > >> CC: penn43 at gmx.com, > "Mika Nystrom" , > m3devel at elegosoft.com > >> Fecha: s?bado, 21 de abril, 2012 16:28 > >> What would be LONGADDRESS? Pointer to > >> a location inside LONGRAM? :) > >> > >> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro > Benavides D. > >> wrote: > >> > >>> Hi all: > >>> If we accept to exist LONGINT and ADDRESS is a > Word.T > >> why we don't have LONGADDRESS? That's you don't > care if > >> that's in UNSAFE TYPE, do you? > >>> Assembly in lining was handled about perfect > in > >> Modula-2 for VMS I wonder why DEC didn't provide > Modula-3 > >> support with that as well. > >>> Thanks in advance > >>> > >>> --- El vie, 20/4/12, Mika Nystrom > >> escribi?: > >>> > >>>> De: Mika Nystrom > >>>> Asunto: Re: [M3devel] Downsides of Modula-3 > ? > >>>> Para: penn43 at gmx.com > >>>> CC: m3devel at elegosoft.com > >>>> Fecha: viernes, 20 de abril, 2012 15:29 > >>>> > >>>> Now that I have the rather unpleasant task > of > >> writing C code > >>>> for a client, > >>>> I have a few things I "like" about C and > that I > >> "miss" > >>>> somewhat when > >>>> I write Modula-3. > >>>> > >>>> I find that I sort of like the C > >> preprocessor. But > >>>> maybe it's just the > >>>> sort of code I'm writing with it... (test > programs, > >> which > >>>> need lots and > >>>> lots of annotations and instrumentation, > something > >> easy to > >>>> do with cpp). > >>>> > >>>> No alloca.... > >>>> > >>>> No varargs... > >>>> > >>>> No real "const" (Java "final"). > Sometimes > >> WITH can do > >>>> it. > >>>> > >>>> No GO TO.............. can't believe I just > wrote > >> that but > >>>> Modula-3 had > >>>> as one of its design objectives to be a > good target > >> for code > >>>> generation, > >>>> and having goto would make that > easier! (Look > >> at the > >>>> C-Mix partial > >>>> evaluator for an application.) > >>>> > >>>> A C++ programmer would undoubtedly miss a > lot of > >> crazy C++ > >>>> stuff > >>>> that lets you do tricky stuff entirely > without > >> heap > >>>> allocation. > >>>> And operator overloading. > >>>> > >>>> Then there are some annoying > implementation > >> limitations: > >>>> > >>>> No EXTENDED floating point in the standard > >> implementation. > >>>> > >>>> Bugs in the "standard" threading library > (pthreads > >>>> based). Have > >>>> to use the longjmp hack version. > >>>> > >>>> Dubious "enhancements" relative to the > Green Book: > >> LONGINT, > >>>> WIDECHAR > >>>> (and a lot of issues with TEXT as a > result). > >> And > >>>> efficiency problems > >>>> in the CM3 code in *some cases* (compared > with the > >> older SRC > >>>> M3). > >>>> > >>>> ---- > >>>> > >>>> My own evaluation of the above is that the > things > >> lacking > >>>> relative to C > >>>> are really pretty minor and the language is > so much > >> easier > >>>> to use > >>>> and better engineered that you almost never > say to > >> yourself > >>>> "oh I wish > >>>> I could write this procedure in C" (you > might say > >> it of one > >>>> line of code). > >>>> > >>>> The implementation issues are things that > could > >> "easily" be > >>>> fixed by > >>>> someone who had the time.. > >>>> > >>>> Oh regarding efficiency problems: I still > find that > >> CM3 with > >>>> optimization > >>>> turned on produces code that runs faster > and with a > >> far > >>>> smaller memory > >>>> footprint than code doing the same thing in > Java, > >> most of > >>>> the time. > >>>> That's when you try to do as close to an > >> apples-to-apples > >>>> comparison > >>>> as possible. If you take into account > the > >> fact that in > >>>> Modula-3 you can > >>>> allocate structured memory in "batches" > (called > >> "arrays"!) > >>>> the difference > >>>> is even bigger. Modula-3 also links > far > >> easier with C > >>>> and Fortran than > >>>> Java does. > >>>> > >>>> Mika > >>>> > >>>> > >>>> > >>>> penn43 at gmx.com > >>>> writes: > >>>>> An object appraisal must take into > account the > >> problems > >>>> too. So I am asking yo > >>>>> u, could you please mention any > downsides of > >> using > >>>> Modula-3, in your experienc > >>>>> e? > >>>>> > >>>>> Of course, the non-existent language > community > >> has > >>>> already been mentioned as a > >>>>> major downside. > >>>>> And the lack of documentation. > >>>>> What about other issues, such as > compiler > >> efficiency? Or > >>>> interaction with fore > >>>>> ign libraries? > >>>>> > >>>>> Thanks > >>>>> > >>>>> Marresh > >>>> > >> > >> > > From dknoto at next.com.pl Tue Apr 24 20:28:05 2012 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?B?S25vY2nxc2tp?=) Date: Tue, 24 Apr 2012 20:28:05 +0200 Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 Message-ID: <20120424202805.26f30211@wenus.next.com.pl> Hello All, I still have not resolved the problem of CM3 build from source on Fedora 16 x86_64. However, I installed Ubuntu 12.04 Beta i686 in VirtualBox and CM3 5.9.0 2012/04/13 compilation went smoothly. So I wonder how it compiles CM3 on x86_64 architecture? Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Tue Apr 24 21:18:09 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 24 Apr 2012 20:18:09 +0100 (BST) Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 In-Reply-To: <20120424202805.26f30211@wenus.next.com.pl> Message-ID: <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: I guess you are asking about how to produce a bootstrap image for cm3-min in LINUXAMD64, and the truth is that it uses the back-end for doing that but Jay knows the details. The front end doesn't know too much about about machine itself (or tries to ignore it) which makes it more portable code though not easier, so all the details might be related with m3gcc In any event, did you try the Fedora 16 package: http://pkgs.org/fedora-16/rpm-sphere-x86_64/cm3-5.8.6-11.1.x86_64.rpm.html It has a cm3 image maybe you could just scripts/do-cm3-std.sh buildship Thanks in advance --- El mar, 24/4/12, Dariusz Knoci?ski escribi?: > De: Dariusz Knoci?ski > Asunto: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > Para: m3devel at elegosoft.com > Fecha: martes, 24 de abril, 2012 13:28 > Hello All, > I still have not resolved the problem of CM3 build from > source on Fedora 16 > x86_64. However, I installed Ubuntu 12.04 Beta i686 in > VirtualBox and CM3 > 5.9.0 2012/04/13 compilation went smoothly. So I wonder how > it compiles CM3 on > x86_64 architecture? > Best regards > Dariusz Knoci?ski. > From jay.krell at cornell.edu Wed Apr 25 05:30:57 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 25 Apr 2012 03:30:57 +0000 Subject: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 In-Reply-To: <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> References: <20120424202805.26f30211@wenus.next.com.pl>, <1335295089.82292.YahooMailClassic@web29706.mail.ird.yahoo.com> Message-ID: The information is buried here: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/doc/notes/porting.txt?rev=1.6;content-type=text%2Fplain - do a build of m3core, libm3, and the pieces that make up cm3, BUT stopping at the output of assembly -- not running the assembler and linker (scripts/python/boot1.py NEWTARGET) - package up (tar/gzip) the assembly files, as well as some .c files (done by boot1.py, sitting in the current working directory) - copy that to the target system (scp or ftp) - unpackage (untar/gzip) - cd step missing here - make - giving us cm3 - use that cm3 to then build the entire system on the new target missing instructions for the last step...but it is just to put cm3 in $PATH and run something in scripts...boot2.py maybe? - Jay > Date: Tue, 24 Apr 2012 20:18:09 +0100 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; dknoto at next.com.pl > Subject: Re: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > > Hi all: > I guess you are asking about how to produce a bootstrap image for cm3-min in LINUXAMD64, and the truth is that it uses the back-end for doing that but Jay knows the details. > > The front end doesn't know too much about about machine itself (or tries to ignore it) which makes it more portable code though not easier, so all the details might be related with m3gcc > > In any event, did you try the Fedora 16 package: > http://pkgs.org/fedora-16/rpm-sphere-x86_64/cm3-5.8.6-11.1.x86_64.rpm.html > > It has a cm3 image maybe you could just scripts/do-cm3-std.sh buildship > > Thanks in advance > > --- El mar, 24/4/12, Dariusz Knoci?ski escribi?: > > > De: Dariusz Knoci?ski > > Asunto: [M3devel] CM3 5.9.0 - compilation problems on Fedora 16/AMD64 > > Para: m3devel at elegosoft.com > > Fecha: martes, 24 de abril, 2012 13:28 > > Hello All, > > I still have not resolved the problem of CM3 build from > > source on Fedora 16 > > x86_64. However, I installed Ubuntu 12.04 Beta i686 in > > VirtualBox and CM3 > > 5.9.0 2012/04/13 compilation went smoothly. So I wonder how > > it compiles CM3 on > > x86_64 architecture? > > Best regards > > Dariusz Knoci?ski. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 25 15:08:03 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 25 Apr 2012 15:08:03 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, what can I say? > Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From dataf4l at gmail.com Wed Apr 25 18:08:28 2012 From: dataf4l at gmail.com (felipe valdez) Date: Wed, 25 Apr 2012 11:08:28 -0500 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: References: <1335278559.42071.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size > per architecture. Of course there are various architectures, with their > various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you > expect one thread of your program to run on one CPU, second thread on > another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, > etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are > planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less > stressful, I mean, even the OS/400 has this feature of 128 pointers to > allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course > this would require more TYPE declarations and VAR as well (LADR, LVAR), but > could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, > what can I say? > Thanks in advance > > > -- 312-444-2124 Skype: f3l.headhunter Casa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 25 21:24:30 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 25 Apr 2012 20:24:30 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier? in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 25 23:37:43 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 25 Apr 2012 23:37:43 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335381870.60711.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <81486992-135C-4366-87A2-C126E45A7B68@m3w.org> Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor > > I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. > > Thanks in advance > > --- El mi?, 25/4/12, felipe valdez escribi?: > > De: felipe valdez > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Dragi?a Duri?" > CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 11:08 > > that is quite a response. > > > On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. >> So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. >> We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. >> >> So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. >> It must be done carefully aggressively because this is a changing world, what can I say? >> Thanks in advance > > > > > -- > 312-444-2124 > Skype: f3l.headhunter > Casa: 8043901 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 26 18:58:38 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Apr 2012 17:58:38 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <81486992-135C-4366-87A2-C126E45A7B68@m3w.org> Message-ID: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. Thank your? LONGINT? is easy just to say? LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER and LONGADDRESS<:ADDRESS so that the same function maps LONGINT ->ADDRESS Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. Thanks in advance --- El mi?, 25/4/12, Dragi?a Duri? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Daniel Alejandro Benavides D." CC: "felipe valdez" , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 16:37 Single "execution space" can span over various architectures ?in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen.? On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space.? It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier? in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Apr 26 19:44:18 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 26 Apr 2012 19:44:18 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Daniel, LONGINT and INTEGER are scalar types with no relation except one's values are subset of another. References to them are strongly typed in Modula-3 - meaning types are semantically different - but their representation is same as ADDRESS. In single address space you have all memory location addressable by same pointer type - ADDRESS. They can differ in alignment, depending on implementation decisions, but that is something else. Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied semantical informationis used where it is needed and it is not worry of language user unless she/he does something related to language environments other than Modula-3. Think RPC, OpenCL (GPU), ... On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, 8byte. Most 64bit platforms today are limited in number of address lines from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am sure it is limited to some number smaller than 64 on every 64bit platform today. But - that does not mean (Modula-3) language implementor will make PHYSADDRESS pointer type 6 bytes long. You probably can find such types in some experimental languages you are interested in. Good luck there, for/but I am not :). Unless my English-foreign is mismatched more than I think to your English-foreign, we are almost orthogonal in this discussion for some time. I checked, I am still writing to m3devel. Are you? :) dd On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. > In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. > Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER > and LONGADDRESS<:ADDRESS so that the same function maps > LONGINT ->ADDRESS > Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. > Thanks in advance > > > --- El mi?, 25/4/12, Dragi?a Duri? escribi?: > > De: Dragi?a Duri? > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Daniel Alejandro Benavides D." > CC: "felipe valdez" , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 16:37 > > Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. > > RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. > > On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. > > GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. > > It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. > > On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? >> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor >> >> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor >> >> I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. >> >> Thanks in advance >> >> --- El mi?, 25/4/12, felipe valdez escribi?: >> >> De: felipe valdez >> Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] >> Para: "Dragi?a Duri?" >> CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com >> Fecha: mi?rcoles, 25 de abril, 2012 11:08 >> >> that is quite a response. >> >> >> On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: >> As my first hands-on CPU was 6502, I think I remember a lot. >> >> ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. >> >> What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? >> >> On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. >>> So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. >>> We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. >>> >>> So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. >>> It must be done carefully aggressively because this is a changing world, what can I say? >>> Thanks in advance >> >> >> >> >> -- >> 312-444-2124 >> Skype: f3l.headhunter >> Casa: 8043901 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dataf4l at gmail.com Thu Apr 26 20:34:08 2012 From: dataf4l at gmail.com (felipe valdez) Date: Thu, 26 Apr 2012 13:34:08 -0500 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Message-ID: English, here, is the keyword. On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: > Daniel, > > LONGINT and INTEGER are scalar types with no relation except one's values > are subset of another. References to them are strongly typed in Modula-3 - > meaning types are semantically different - but their representation is same > as ADDRESS. In single address space you have all memory location > addressable by same pointer type - ADDRESS. They can differ in alignment, > depending on implementation decisions, but that is something else. > Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied > semantical informationis used where it is needed and it is not worry of > language user unless she/he does something related to language environments > other than Modula-3. Think RPC, OpenCL (GPU), ... > > On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, > 8byte. Most 64bit platforms today are limited in number of address lines > from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am > sure it is limited to some number smaller than 64 on every 64bit platform > today. But - that does not mean (Modula-3) language implementor will make > PHYSADDRESS pointer type 6 bytes long. You probably can find such types in > some experimental languages you are interested in. Good luck there, for/but > I am not :). > > Unless my English-foreign is mismatched more than I think to your > English-foreign, we are almost orthogonal in this discussion for some time. > I checked, I am still writing to m3devel. Are you? :) > > dd > > On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > In that sense, it's neither Physical or logical but process communications > are both (so hat's why its called Inter-process), but conceptually, you can > speak of that if that's what you mean. > In one of such architectures (as a Bus-oriented architecture > micro-processor) there are Logical Address (INTEGER), as the direction of a > physical processor bus ID, (where there is a one to one mapping LBID to > PBID) or a System Bus ID (ADDRESS), which identifies the location of a > kernel function. > Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because > you would want such a type of LBID address and function location, wouldn't > you? And then the location itself is and expressed by REF LONGINT<:REF > INTEGER > and LONGADDRESS<:ADDRESS so that the same function maps > LONGINT ->ADDRESS > Modula-3 type hierarchy does say that, doesn't it? This is because it is > contra variant type hierarchy. > Thanks in advance > > > --- El *mi?, 25/4/12, Dragi?a Duri? * escribi?: > > > De: Dragi?a Duri? > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Daniel Alejandro Benavides D." > CC: "felipe valdez" , m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 16:37 > > Single "execution space" can span over various architectures in few ways. > Examples - RPC and GPU. > > RPC is nothing new and it does not presume multi architecture for single > object file. Nor it presumes single address space for various > components/processes. There is cross-process boundary where conversions > (data marshaling/unmarshalling) happen. > > On the other hand, GPU programming? No cross-process boundary in RPC > style, it almost looks like it is single executable - but it is not > "multiple CPU architecture per single object". Nor does it include single > address space for various object components included. > > GPU is an excellent example of what you are, very obliquely, hinting at. > But - it is not single object file for multiple architectures for single > address space. > > It is probably good idea for you to look at GPU's today to see what is > realistic in multi-architecture object generation/application. > > On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > Such as a module generating code, for sending both LONGINTs and > LONGADDRESSes through networks of wide processing units MCU (e.g array > processors)? > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor > > http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor > > I guess I should tell you one, but there are too many to count examples, > in any case you would want to be truly multi platform and cross-porting > easier in general, rather than based in one base case, though Modula was > too good to make such things difficult in any case. If it serves to know > multitasking of DEC has been emulated through the AMD Bulldozer > microarchitecture with Array/Vector processor, etc. But it still needs more > cooperation (or at least using shared standards) on the industry to return > to those good days. > > Thanks in advance > > --- El *mi?, 25/4/12, felipe valdez * escribi?: > > > De: felipe valdez > Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] > Para: "Dragi?a Duri?" > CC: "Daniel Alejandro Benavides D." , > m3devel at elegosoft.com > Fecha: mi?rcoles, 25 de abril, 2012 11:08 > > that is quite a response. > > > On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: > > As my first hands-on CPU was 6502, I think I remember a lot. > > ADDRESS is pointer size, and even C world spins around one pointer size > per architecture. Of course there are various architectures, with their > various specifics. Not only pointer size, of course. > > What use would be to have two pointer sizes in single project? Do you > expect one thread of your program to run on one CPU, second thread on > another, different CPU? > > On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: > > Hi all: > All the contrary Dragisha, do you remember the Micro's era 6809, 4004, > etc, so then it became gradually 68000, 8088 - 80186, etc. > So we can see in ARM versions, but now, probably in AMD64, that they are > planning the next step, as were the same histories for those days. > We could use it like for porting 32 bit backend to 64 bit painfully less > stressful, I mean, even the OS/400 has this feature of 128 pointers to > allow updating architecture, without language change. > > So I'd guess is rather cross-portability, upwards and that's it. Of course > this would require more TYPE declarations and VAR as well (LADR, LVAR), but > could be less painful for the ones who want to port to that. > It must be done carefully aggressively because this is a changing world, > what can I say? > Thanks in advance > > > > > > -- > 312-444-2124 > Skype: f3l.headhunter > Casa: 8043901 > > > > > -- 312-444-2124 Skype: f3l.headhunter Casa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Apr 26 20:56:59 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Apr 2012 19:56:59 +0100 (BST) Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: Message-ID: <1335466619.60883.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: Well, I'm not so passing the fact that it is a computer more than a language what we are talking here. I was reading had several kinds of invariant type rules or covariant ones, but they found it was harder than they thought, so, I'm more type-orthogonal as such in Modula-3, the questions are more related to that than how to control language capabilities, which are very much simplified, however no many languages try to do the other part see what's in the machine. I think Dragisha's point is whether I reply myself, or just himself. So I don't care if anybody responses that's for sure, thought I won't do that my self. Thanks in advance --- El jue, 26/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: jueves, 26 de abril, 2012 13:34 English, here, is the keyword. On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: Daniel, LONGINT and INTEGER are scalar types with no relation except one's values are subset of another. References to them are strongly typed in Modula-3 - meaning types are semantically different - but their representation is same as ADDRESS. In single address space you have all memory location addressable by same pointer type - ADDRESS. They can differ in alignment, depending on implementation decisions, but that is something else. Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied semantical informationis used where it is needed and it is not worry of language user unless she/he does something related to language environments other than Modula-3. Think RPC, OpenCL (GPU), ... On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, 8byte. Most 64bit platforms today are limited in number of address lines from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am sure it is limited to some number smaller than 64 on every 64bit platform today. But - that does not mean (Modula-3) language implementor will make PHYSADDRESS pointer type 6 bytes long. You probably can find such types in some experimental languages you are interested in. Good luck there, for/but I am not :). Unless my English-foreign is mismatched more than I think to your English-foreign, we are almost orthogonal in this discussion for some time. I checked, I am still writing to m3devel. Are you? :) dd On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote: Hi all: In that sense, it's neither Physical or logical but process communications are both (so hat's why its called Inter-process), but conceptually, you can speak of that if that's what you mean. In one of such architectures (as a Bus-oriented architecture micro-processor) there are Logical Address (INTEGER), as the direction of a physical processor bus ID, (where there is a one to one mapping LBID to PBID) or a System Bus ID (ADDRESS), which identifies the location of a kernel function. Thank your LONGINT is easy just to say LONGINT->LONGADDRESS, because you would want such a type of LBID address and function location, wouldn't you? And then the location itself is and expressed by REF LONGINT<:REF INTEGER and LONGADDRESS<:ADDRESS so that the same function maps LONGINT ->ADDRESS Modula-3 type hierarchy does say that, doesn't it? This is because it is contra variant type hierarchy. Thanks in advance --- El mi?, 25/4/12, Dragi?a Duri? escribi?: De: Dragi?a Duri? Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Daniel Alejandro Benavides D." CC: "felipe valdez" , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 16:37 Single "execution space" can span over various architectures in few ways. Examples - RPC and GPU. RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. On the other hand, GPU programming? No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included. GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application. On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote: Hi all: Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)? http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days. Thanks in advance --- El mi?, 25/4/12, felipe valdez escribi?: De: felipe valdez Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] Para: "Dragi?a Duri?" CC: "Daniel Alejandro Benavides D." , m3devel at elegosoft.com Fecha: mi?rcoles, 25 de abril, 2012 11:08 that is quite a response. On Wed, Apr 25, 2012 at 8:08 AM, Dragi?a Duri? wrote: As my first hands-on CPU was 6502, I think I remember a lot. ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course. What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU? On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote: Hi all: All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc. So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days. We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change. So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that. It must be done carefully aggressively because this is a changing world, what can I say? Thanks in advance -- 312-444-2124 Skype: f3l.headhunterCasa: 8043901 -- 312-444-2124Skype: f3l.headhunterCasa: 8043901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 26 22:36:03 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 26 Apr 2012 16:36:03 -0400 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> Message-ID: <20120426203603.GF4670@topoi.pooq.com> On Thu, Apr 26, 2012 at 01:34:08PM -0500, felipe valdez wrote: > English, here, is the keyword. > > > On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: > > > Daniel, > > > > On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, > > 8byte. Most 64bit platforms today are limited in number of address lines > > from CPU to memory, The rest can still be used within the processor for addressing virtual memory, which can be mapped to physical memory in a bewildering variety of ways, and can exceed physical RAM. -- hendrik From dragisha at m3w.org Thu Apr 26 23:31:02 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 26 Apr 2012 23:31:02 +0200 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <20120426203603.GF4670@topoi.pooq.com> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> <20120426203603.GF4670@topoi.pooq.com> Message-ID: <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> And still - ADDRESS type is 64bit. No 48, no 54 - but 64. As all (L|I)?LP64 pointer types are. On Apr 26, 2012, at 10:36 PM, Hendrik Boom wrote: > On Thu, Apr 26, 2012 at 01:34:08PM -0500, felipe valdez wrote: >> English, here, is the keyword. >> >> >> On Thu, Apr 26, 2012 at 12:44 PM, Dragi?a Duri? wrote: >> >>> Daniel, >>> >>> On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit, >>> 8byte. Most 64bit platforms today are limited in number of address lines >>> from CPU to memory, > > The rest can still be used within the processor for addressing virtual > memory, which can be mapped to physical memory in a bewildering variety > of ways, and can exceed physical RAM. > > -- hendrik From dabenavidesd at yahoo.es Fri Apr 27 04:50:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 27 Apr 2012 03:50:04 +0100 (BST) Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <4F94513B.3060802@lcwb.coop> Message-ID: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Have you read this, if the answer is not, maybe you should, because it seems, this person knows that from the beginning there were problems in the language specification in thread semantics. https://groups.google.com/group/comp.arch/msg/880a211df40506ab?hl=en Rodney (and Mika), please make sure your code (implementation) is OK with standard semantics likewise I will do try to accept the Modula-3 semantics of threads are OK, hum, this could be fun, but, very hard, even Larch/Modula-3 might not be able to correct every error on it (so then I might say that is correct and safe, but anything SAFE). Of course there will always room running in circles but still is better to check if something else can be done properly, I mean, that you can't be safe-threaded for %100, can you? That's maybe why they drop the word SAFE for Modula-3 and that's good, they are honest. Thanks in advance --- El dom, 22/4/12, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Downsides of Modula-3 ? > Para: m3devel at elegosoft.com > Fecha: domingo, 22 de abril, 2012 13:43 > > > On 04/22/2012 11:41 AM, Daniel Alejandro Benavides D. > wrote: > > Hi all: > > I'm more suspicious about the back needs over this > programs, since Win32 programs have worked OK, have they? So > I agree with you it's a matter of target implementation (not > UNSAFE world), but that's in m3gcc backend, isn't it? > > Similarly your code could be fixed to uniprocessor > semantics, so if this tests are OK either pthreads or > embedded M3 threads this is a clear symptom of that UP > semantics issue. > > In any case don't expect too many threads to do that > correctly, since any exception in them can't be managed by > Modula-3 RT > (by language definition) > > I'm not sure what you mean by this, but in my reading, the > language definition fully defines the interaction > between threads and exceptions. Exceptions can > propagate only within a thread. All the rules about > where > they propagate are in terms of either a statically enclosing > block or a dynamic parent, that is, the caller > of the current procedure. In both cases, it's strictly > within the thread where the exception was raised. > > If an exception ever got to the top of the call chain of its > thread, it would have to be the result of an > override of the apply method of the closure passed to > Thread.Fork. But that method has an empty RAISES > clause, so if that should happen, it would be a runtime > error, still within the thread. > > but at most in m3gcc semantics I believe so. DECthreads had > a nice mechanism to wrap it to Modula-3 style semantics > so it could be easier to offer that in a internal CM3 API. > > Thanks in advance > > > > > > --- El s?b, 21/4/12, Mika Nystrom > escribi?: > > > >> De: Mika Nystrom > >> Asunto: Re: [M3devel] Downsides of Modula-3 ? > >> Para: "Jay K" > >> CC: m3devel at elegosoft.com > >> Fecha: s?bado, 21 de abril, 2012 18:36 > >> Jay K writes: > >>> 1) please elaborate > >> > >>> 2) We don't use longjmp as much any more=2C > but > >> get/set= > >>> /make/swapcontext on platforms that support > them.And > >> where we do use longjm= > >>> p=2C we have a more portable use than before -- > we no > >> longer hack on the jm= > >>> pbuf.There is a "trick" where you use > sigsetstack or > >> some such to get the s= > >>> tack pointer into the jmpbuf.Look at the code > and read > >> the paper referenced= > >>> . It is possible it didn't work on all > platforms. > >> But anyway=2C see #1.We'= > >>> d really prefer to just use pthreads.Hm. I'd > like to > >> look again at what pth= > >>> reads features we use -- I suspect > pthreads/Win32 can > >> beabstracted more thi= > >>> nly and the Modula-3 code > less-forked/more-shared. But > >> later.. - Jay> Fro= > >> > >> Sorry for the bad quote. My mailer still > lives in the > >> 7-bit world. > >> > >> In any case I was just mentioning as a problem with > the > >> current Modula-3 > >> implementation that the pthreads bindings are > buggy. I > >> would not (and > >> do not) use them for serious work. And user > threads > >> are, as we all know, > >> not ideal... > >> > >> Anybody who wants to investigate the matter can > start by > >> running the thread > >> testing program in m3core/tests/thread ... > Main.m3 is > >> fairly well documented. > >> > >> Mika > >> > > > From mika at async.caltech.edu Fri Apr 27 05:02:28 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Apr 2012 20:02:28 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: <20120427030228.B46BC1A205B@async.async.caltech.edu> "Daniel Alejandro Benavides D." writes: >Hi all: >Have you read this, if the answer is not, maybe you should, because it seem= >s, this person knows that from the beginning there were problems in the lan= >guage specification in thread semantics. >https://groups.google.com/group/comp.arch/msg/880a211df40506ab?hl=3Den > >Rodney (and Mika), please make sure your code (implementation) is OK with s= >tandard semantics likewise I will do try to accept the Modula-3 semantics o= >f threads are OK, hum, this could be fun, but, very hard, even Larch/Modula= >-3 might not be able to correct every error on it (so then I might say that= > is correct and safe, but anything SAFE). Of course there will always room = >running in circles but still is better to check if something else can be do= >ne properly, I mean, that you can't be safe-threaded for %100, can you? Tha= >t's maybe why they drop the word SAFE for Modula-3 and that's good, they ar= >e honest. >Thanks in advance I think the early specs of the Modula-3 threads were a bit loose, yes. I am pretty sure this was corrected for the formal verification. You can read about this in the Green Book, too. It is interesting that the author of the thread to which you refer essentially claims that C doesn't guarantee what one might think it claims. This would suggest that there may be things one shouldn't assume about pthreads. My Modula-3 code (in the thread tester program) is really nothing special. Please review it yourself and let me know if you find any issues. It's not particularly complicated... Mika From dragisha at m3w.org Fri Apr 27 09:41:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 09:41:29 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427030228.B46BC1A205B@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> Message-ID: <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> On Apr 27, 2012, at 5:02 AM, Mika Nystrom wrote: > > It is interesting that the author of the thread to which you refer essentially > claims that C doesn't guarantee what one might think it claims. This would suggest > that there may be things one shouldn't assume about pthreads. There is well known paper by Hans Boehm, possibly of interest to Daniel: http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html He cites Java Memory Model paper (also of possible interest here) and Boehm states problem is being addressed at moment. So, it's maybe only of historical interest now. > My Modula-3 code (in the thread tester program) is really nothing special. > Please review it yourself and let me know if you find any issues. > It's not particularly complicated? When I was implementing NPTL based threads for pm3 (around 2004) I met interesting issues with few thread programs in pm3 distribution. Those programs were written and tested with user space threads where order of thread execution was, for ready threads, always same. One was pp, as I remember... I am reading your source code just now. And one thing caught my eye: "Each type of thread starts by sleeping for a while, to give the other threads a chance to be created." Does not look like any guarantee to me, not in threaded application. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Apr 27 10:26:09 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 10:26:09 +0200 Subject: [M3devel] thread test (Mika) Message-ID: Did anyone run combinations of tests and found minimal test sets where breaks happen? I tried read,alloc and it breaks. read only does not. From small number of tests I performed, it looks like RTAllocator is real culprit here. Most breaks happens while allocating, even one I saw in FileRd.Init() while running -tests read,alloc . From dragisha at m3w.org Fri Apr 27 10:53:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 10:53:29 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: References: Message-ID: <765A576E-5D12-424A-BFFE-C06F51472A03@m3w.org> Oh, it does :). In FileRd.Init(). And during stop-the-world. IIRC, Tony mentioned allocation is solved by giving separate page to every thread to allocate new data from. It looks like straightforward method, and problem proof. But it also has border mooments where new pages are given to threads. Also a problem - world suspension from garbage collector. In less than 10 starts whole system deadlocked at least four times. On Apr 27, 2012, at 10:26 AM, Dragi?a Duri? wrote: > I tried read,alloc and it breaks. read only does not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Apr 27 19:13:40 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Apr 2012 10:13:40 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> Message-ID: <20120427171341.0D83E1A205E@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: ... >I am reading your source code just now. And one thing caught my eye: = >"Each type of thread starts by sleeping for a while, to give the other = >threads a chance to be created." Does not look like any guarantee to me, = >not in threaded application.=20= If the program prints "running" then all threads have been created. It eventually prints "running". Therefore all threads are created. --- The things wrong with CM3's pthreads threading are NOT subtle. The runtime completely freezes up, ctrl-C stops working, and other such things. Mika From dragisha at m3w.org Fri Apr 27 19:30:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 19:30:29 +0200 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427171341.0D83E1A205E@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> Message-ID: I do not doubt they are created. Probably not an issue with 3 threads here, 3 threads there, but it can be if one relies on "must be created after some arbitrary time" in any synchronization. I did, and SRC people did, at least in two places. I just don't see it as a good practice. BTW, your test is excellent stress machine. My laptops hate it, probably, till now :). Right now I am focused on an allocation race issue and I hope to fix it in few hours/a day. On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > ... >> I am reading your source code just now. And one thing caught my eye: = >> "Each type of thread starts by sleeping for a while, to give the other = >> threads a chance to be created." Does not look like any guarantee to me, = >> not in threaded application.=20= > > If the program prints "running" then all threads have been created. > > It eventually prints "running". > > Therefore all threads are created. > > --- > > The things wrong with CM3's pthreads threading are NOT subtle. > The runtime completely freezes up, ctrl-C stops working, and other > such things. > > Mika From mika at async.caltech.edu Fri Apr 27 19:49:48 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Apr 2012 10:49:48 -0700 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> Message-ID: <20120427174948.9BB191A205B@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >I do not doubt they are created. Probably not an issue with 3 threads = >here, 3 threads there, but it can be if one relies on "must be created = >after some arbitrary time" in any synchronization. I did, and SRC people = >did, at least in two places. I just don't see it as a good practice. Yes I have had that bug in my programs a few times. But to be really fair it's not that you're assuming that another thread is created by a certain time but you're assuming that it has done something by the time the first thread needs to do something else. In the examples of the sort you describe it is usually that the newly created thread has "had time to initialize" (in some way). My bug with this was of this nature: thread A: ... Thread.Fork(b)... wait... LOCK(b.mu) Thread B: ... self.mu := NEW(MUTEX) ... Oops! works on some threading implementations (user threads). Instant segfault on others! Have fun with the thread tester. It doesn't find any problems with user threads. I should probably have dug into the pthreads myself long ago but it's always so far down the todo list, and all my CM3 installations use user threads by necessity. If you can improve the pthreads I think it would make me much happier about CM3 in general. I still use PM3 as much as possible... Mika > >BTW, your test is excellent stress machine. My laptops hate it, = >probably, till now :). Right now I am focused on an allocation race = >issue and I hope to fix it in few hours/a day. > >On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: > >> =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >> ... >>> I am reading your source code just now. And one thing caught my eye: = >=3D >>> "Each type of thread starts by sleeping for a while, to give the = >other =3D >>> threads a chance to be created." Does not look like any guarantee to = >me, =3D >>> not in threaded application.=3D20=3D >>=20 >> If the program prints "running" then all threads have been created. >>=20 >> It eventually prints "running". >>=20 >> Therefore all threads are created. >>=20 >> --- >>=20 >> The things wrong with CM3's pthreads threading are NOT subtle. >> The runtime completely freezes up, ctrl-C stops working, and other >> such things. >>=20 >> Mika From dragisha at m3w.org Fri Apr 27 20:13:20 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 20:13:20 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> References: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> Message-ID: This particular deadlock/fix is observed and fixed for AMD64_LINUX. First change is just because it is same pattern. I ddidn't check if that code is used at all. Second change is our fix. With this, Mika's threadtest -tests alloc works. This is very probably fix for lots of situations tripped by his test and also for applications with heavy heap usage. dd p.s. Olaf/Michael, please teach me (again) how to commit this . It was long time since I commited anything to CVS :). Index: src/thread/PTHREAD/ThreadPThread.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v retrieving revision 1.259 diff -U 2 -r1.259 ThreadPThread.m3 --- src/thread/PTHREAD/ThreadPThread.m3 16 Jan 2011 21:25:21 -0000 1.259 +++ src/thread/PTHREAD/ThreadPThread.m3 27 Apr 2012 18:06:43 -0000 @@ -782,4 +782,5 @@ <*ASSERT act.state # ActState.Starting*> IF act.state # ActState.Stopped THEN + SetState(act, ActState.Stopping); SignalThread(act); INC(newlySent); @@ -971,4 +972,5 @@ <*ASSERT act.state # ActState.Starting*> IF act.state # ActState.Stopped THEN + SetState(act, ActState.Stopping); SignalThread(act); INC(newlySent); On Apr 27, 2012, at 3:04 PM, Antony Hosking wrote: > Platform? > Thread stack dump? > I assume it is a deadlock. > If not deadlock then what? > Diagnosis would then allow us to fix. > > Sent from my iPhone > > On Apr 27, 2012, at 3:26 AM, Dragi?a Duri? wrote: > >> Did anyone run combinations of tests and found minimal test sets where breaks happen? >> >> I tried read,alloc and it breaks. read only does not. >> >> From small number of tests I performed, it looks like RTAllocator is real culprit here. Most breaks happens while allocating, even one I saw in FileRd.Init() while running -tests read,alloc . From dragisha at m3w.org Fri Apr 27 21:30:16 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 21:30:16 +0200 Subject: [M3devel] Mika's thread test, -tests read Message-ID: Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. dd === (gdb) bt #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) at ../src/runtime/common/RTCollector.m3:1091 #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, thread=) at ../src/runtime/common/RTAllocator.m3:367 #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) info threads Id Target Id Frame * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 (gdb) thr 3 From wagner at elegosoft.com Fri Apr 27 22:13:35 2012 From: wagner at elegosoft.com (mail.elegosoft.com) Date: Fri, 27 Apr 2012 22:13:35 +0200 Subject: [M3devel] thread test (Mika) In-Reply-To: References: <9C522C25-A829-4A22-BCA7-D28D0DEAB620@gmail.com> Message-ID: <20120427221335.699cc2ed.wagner@elegosoft.com> On Fri, 27 Apr 2012 20:13:20 +0200 Dragi?a Duri? wrote: > This particular deadlock/fix is observed and fixed for AMD64_LINUX. First change is just because it is same pattern. I ddidn't check if that code is used at all. Second change is our fix. > > With this, Mika's threadtest -tests alloc works. This is very probably fix for lots of situations tripped by his test and also for applications with heavy heap usage. > > dd > > p.s. Olaf/Michael, please teach me (again) how to commit this . It was long time since I commited anything to CVS :). If you've got the change in a workspace checked out via cvs/ssh, you just need to call `cvs commit' or `cvs commit -m "some meaningful log message"'. I assume that you have ssh access to m3.elegosoft.com. If not, Mike can set it up for you if you provide a key, or I can commit your changes if there are only a few of them. You may want to read http://www.elegosoft.com/en/solutions/modula-3/cvs-ssh-access.html if you haven't got ssh access yet. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Apr 27 22:21:22 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 27 Apr 2012 16:21:22 -0400 Subject: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?] In-Reply-To: <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> References: <1335459518.79105.YahooMailClassic@web29704.mail.ird.yahoo.com> <45ACA034-0FBB-4C46-87C5-E7B301BB3001@m3w.org> <20120426203603.GF4670@topoi.pooq.com> <7B0A7473-BAC5-488F-B1C0-D0574F3A9A7D@m3w.org> Message-ID: <20120427202122.GF30181@topoi.pooq.com> On Thu, Apr 26, 2012 at 11:31:02PM +0200, Dragi?a Duri? wrote: > And still - ADDRESS type is 64bit. No 48, no 54 - but 64. As all (L|I)?LP64 pointer types are. Exactly! -- hendrik From dragisha at m3w.org Fri Apr 27 22:51:42 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 22:51:42 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: Message-ID: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> Another one, pretty "clean". Other threads are using their local memory, nothing shared execpt, of course, heap. Also, no visible pattern (yet) in other thread states/stacks when one of them breaks at this point. This, an RTCollector.Move() reported earlier, are two breaks in this test. === Creating nxread threads...[New Thread 0x7ffff7fd1700 (LWP 24756)] [New Thread 0x7ffff77d0700 (LWP 24757)] [New Thread 0x7ffff6fcf700 (LWP 24758)] done running...printing oldest/median age/newest ..........laziest thread is 0/0/0 (tests: nxread 0/0/0) ..........laziest thread is 0/0/0 (tests: nxread 0/0/0) . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7fd1700 (LWP 24756)] 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 44 IF (rd.buff = NIL) THEN (gdb) bt #0 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 #1 0x000000000041831d in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 #2 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 #3 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #4 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #5 0x0000003bed807d90 in start_thread (arg=0x7ffff7fd1700) at pthread_create.c:309 #6 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) info threads Id Target Id Frame 4 Thread 0x7ffff6fcf700 (LWP 24758) "threadtest" UnsafeRd__FastGetChar (rd=) at ../src/rw/Rd.m3:44 3 Thread 0x7ffff77d0700 (LWP 24757) "threadtest" 0x000000000044f405 in ThreadPThread__LockMutex (m=) at ../src/thread/PTHREAD/ThreadPThread.m3:115 * 2 Thread 0x7ffff7fd1700 (LWP 24756) "threadtest" 0x00000000004183db in FileRd__Init (rd=, h=) at ../src/rw/FileRd.m3:44 1 Thread 0x7ffff7fd3700 (LWP 24752) "threadtest" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 (gdb) On Apr 27, 2012, at 9:30 PM, Dragi?a Duri? wrote: > Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. From dragisha at m3w.org Fri Apr 27 23:11:51 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 27 Apr 2012 23:11:51 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> Message-ID: <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Yes. [New Thread 0x7ffff7fd1700 (LWP 24695)] [New Thread 0x7ffff77d0700 (LWP 24696)] [New Thread 0x7ffff6fcf700 (LWP 24697)] done running...printing oldest/median age/newest . Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff77d0700 (LWP 24696)] 0x00000000004374e5 in RTCollector__Move (self=, cp=) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) bt ... I am using unchanged thread test from m3core/tests/thread with only -tests nxread as argument. On AMD64_LINUX, mostly, although I had breaks on AMD64_DARWIN too. I'll print future breaks with C stacks. dd On Apr 27, 2012, at 11:03 PM, Antony Hosking wrote: > Is this one a SIGSEGV? > > On Apr 27, 2012, at 3:30 PM, Dragi?a Duri? wrote: > >> Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. >> >> dd >> === >> (gdb) bt >> #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) >> at ../src/runtime/common/RTCollector.m3:409 >> #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) >> at ../src/runtime/common/RTHeapMap.m3:202 >> #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:62 >> #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 >> #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) >> at ../src/runtime/common/RTCollector.m3:1091 >> #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 >> #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >> #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, >> thread=) at ../src/runtime/common/RTAllocator.m3:367 >> #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 >> #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 >> #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 >> #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 >> #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 >> #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 >> #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 >> #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 >> #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 >> #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 >> (gdb) info threads >> Id Target Id Frame >> * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, >> cp=) at ../src/runtime/common/RTCollector.m3:409 >> 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >> (gdb) thr 3 >> > From dragisha at m3w.org Sat Apr 28 08:49:25 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 08:49:25 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Message-ID: What is stack redzone? Undetected stack overflows or almost overflows? It's not only AMD64_* if it's any consolation: :) frodo:dragisha/pts/0: m3/thread/src% ../LINUXLIBC6/threadtest -tests read,alloc Writing file...done Creating read threads...done Creating alloc threads...done running...printing oldest/median age/newest . *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80792f0 = Move + 0x54 in ../src/runtime/common/RTCollector.m3 *** On Apr 27, 2012, at 11:34 PM, Antony Hosking wrote: > I wonder if we are not seeing the stack redzone on x86-64 and so losing references. > > On Apr 27, 2012, at 5:11 PM, Dragi?a Duri? wrote: > >> Yes. >> [New Thread 0x7ffff7fd1700 (LWP 24695)] >> [New Thread 0x7ffff77d0700 (LWP 24696)] >> [New Thread 0x7ffff6fcf700 (LWP 24697)] >> done >> running...printing oldest/median age/newest >> . >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7ffff77d0700 (LWP 24696)] >> 0x00000000004374e5 in RTCollector__Move (self=, cp=) >> at ../src/runtime/common/RTCollector.m3:409 >> 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; >> (gdb) bt >> ... >> >> I am using unchanged thread test from m3core/tests/thread with only -tests nxread as argument. On AMD64_LINUX, mostly, although I had breaks on AMD64_DARWIN too. >> >> I'll print future breaks with C stacks. >> >> dd >> >> On Apr 27, 2012, at 11:03 PM, Antony Hosking wrote: >> >>> Is this one a SIGSEGV? >>> >>> On Apr 27, 2012, at 3:30 PM, Dragi?a Duri? wrote: >>> >>>> Interesting one.. RTCollector.Move. Thread suspension went well, looks like all problem is with AllocTraced() trigerring a collection. >>>> >>>> dd >>>> === >>>> (gdb) bt >>>> #0 0x00000000004374e5 in RTCollector__Move (self=, cp=) >>>> at ../src/runtime/common/RTCollector.m3:409 >>>> #1 0x000000000046c320 in RTHeapMap__Walk (x=, pc=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:202 >>>> #2 0x000000000046b9b7 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:62 >>>> #3 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:57 >>>> #4 0x000000000046b979 in RTHeapMap__DoWalkRef (t=, a=, v=) >>>> at ../src/runtime/common/RTHeapMap.m3:57 >>>> #5 0x000000000046b90b in RTHeapMap__WalkRef (h=, v=) at ../src/runtime/common/RTHeapMap.m3:47 >>>> #6 0x0000000000439b8d in RTCollector__CleanBetween (h=, he=, clean=) >>>> at ../src/runtime/common/RTCollector.m3:1091 >>>> #7 0x0000000000439995 in RTCollector__CleanPage (page=) at ../src/runtime/common/RTCollector.m3:1064 >>>> #8 0x0000000000439065 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >>>> #9 0x000000000043875b in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>>> #10 0x0000000000438438 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>>> #11 0x00000000004355c7 in RTAllocator__AllocTraced (dataSize=, dataAlignment=, >>>> thread=) at ../src/runtime/common/RTAllocator.m3:367 >>>> #12 0x00000000004345f8 in RTAllocator__GetTracedObj (def=) at ../src/runtime/common/RTAllocator.m3:224 >>>> #13 0x0000000000433efb in RTHooks__AllocateTracedObj (defn=) at ../src/runtime/common/RTAllocator.m3:122 >>>> #14 0x000000000042a4eb in FilePosix__New (fd=, ds=) at ../src/os/POSIX/FilePosix.m3:63 >>>> #15 0x000000000042c286 in FS__OpenFileReadonly (pn=) at ../src/os/POSIX/FSPosix.m3:182 >>>> #16 0x00000000004182f3 in FileRd__Open (p=) at ../src/rw/FileRd.m3:16 >>>> #17 0x00000000004051c4 in Main__NApply (cl=) at ../src/Main.m3:208 >>>> #18 0x0000000000451424 in ThreadPThread__RunThread (me=) at ../src/thread/PTHREAD/ThreadPThread.m3:450 >>>> #19 0x00000000004510df in ThreadPThread__ThreadBase (param=) at ../src/thread/PTHREAD/ThreadPThread.m3:422 >>>> #20 0x0000003bed807d90 in start_thread (arg=0x7ffff6fcf700) at pthread_create.c:309 >>>> #21 0x0000003bed4f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 >>>> (gdb) info threads >>>> Id Target Id Frame >>>> * 4 Thread 0x7ffff6fcf700 (LWP 24429) "threadtest" 0x00000000004374e5 in RTCollector__Move (self=, >>>> cp=) at ../src/runtime/common/RTCollector.m3:409 >>>> 3 Thread 0x7ffff77d0700 (LWP 24428) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> 2 Thread 0x7ffff7fd1700 (LWP 24427) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> 1 Thread 0x7ffff7fd3700 (LWP 24423) "threadtest" 0x0000003bed436604 in do_sigsuspend (set=0xeb41a0) >>>> at ../sysdeps/unix/sysv/linux/sigsuspend.c:63 >>>> (gdb) thr 3 >>>> >>> >> > From dragisha at m3w.org Sat Apr 28 09:57:59 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 09:57:59 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> Message-ID: RTFM helps, as always? No, I don't think it is redzone. BUT. One run: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4200 thread 0x10f] 0x0000000100037360 in RTCollector__Move (self=Cannot access memory at address 0xffffffffffffff77 ) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) ===== Next run: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4204 thread 0x40f] 0x0000000100017e6b in FileRd__Init (rd=Cannot access memory at address 0xffffffffffffffa7 ) at ../src/rw/FileRd.m3:44 44 IF (rd.buff = NIL) THEN ===== Next: ===== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4207 thread 0x1703] 0x0000000100037360 in RTCollector__Move (self=Cannot access memory at address 0xffffffffffffff77 ) at ../src/runtime/common/RTCollector.m3:409 409 IF hdr.typecode = RT0.TextLitTypecode THEN RETURN END; (gdb) p hdr Cannot access memory at address 0xffffffffffffffdf << local variable ===== And so on? Break in FileRd.Init() happens after AllocTraced() takes LongAlloc() route. Break in Move happens along AllocTraced->CollectEnough. Interesting thing - previous call to AllocTraced took a LongAlloc() route. C trace, in Move() break: ===== (gdb) set lang c (gdb) bt #0 0x0000000100037360 in RTCollector__Move (self=0x100953c60, cp=0x100e50018) at ../src/runtime/common/RTCollector.m3:409 #1 0x00000001000358ca in RTHeapMap__Walk (x=0x0, pc=0x1009c0028, v=0x100098a88) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x0000000100034fb2 in RTHeapMap__DoWalkRef (t=0x1, a=0x100083de8, v=0x1009c0028) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100087898, a=0x100084848, v=0x1009c0018) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100d09a30, a=0x100084a48, v=0x1009c0018) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x0000000100034f21 in RTHeapMap__WalkRef (h=0x2018, v=0x1009c0010) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x000000010003986a in RTCollector__CleanBetween (h=0x0, he=0x1009c0010, clean=0 '\0') at ../src/runtime/common/RTCollector.m3:1091 #7 0x0000000100039674 in RTCollector__CleanPage (page=0x1009d0000) at ../src/runtime/common/RTCollector.m3:1064 #8 0x0000000100038dd5 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #9 0x0000000100038532 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #10 0x000000010003820f in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 ===== Lines can differ, as I've put few RTIO.* lines in RTAllocator/Collector. On Apr 28, 2012, at 8:49 AM, Dragi?a Duri? wrote: > What is stack redzone? Undetected stack overflows or almost overflows? From dragisha at m3w.org Sat Apr 28 10:02:40 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 10:02:40 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> References: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> Message-ID: (this and previous email - AMD64_DARWIN) r -tests read,alloc @M3paranoidgc Starting program: /Users/dragisha/m3/thread/AMD64_DARWIN/threadtest -tests read,alloc @M3paranoidgc ... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 [Switching to process 4249 thread 0x1703] 0x000000010003bba1 in RTCollector__RefSanityCheck (v=Cannot access memory at address 0xffffffffffffffa7 ) at ../src/runtime/common/RTCollector.m3:1702 1702 tc := h.typecode; (gdb) set lang c (gdb) bt #0 0x000000010003bba1 in RTCollector__RefSanityCheck (v=0x0, cp=0x100980958) at ../src/runtime/common/RTCollector.m3:1702 #1 0x00000001000358ca in RTHeapMap__Walk (x=0x0, pc=0x100e20028, v=0x100098a88) at ../src/runtime/common/RTHeapMap.m3:202 #2 0x0000000100034fb2 in RTHeapMap__DoWalkRef (t=0x1, a=0x100083de8, v=0x100e20028) at ../src/runtime/common/RTHeapMap.m3:62 #3 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100087898, a=0x100084848, v=0x100e20018) at ../src/runtime/common/RTHeapMap.m3:57 #4 0x0000000100034f85 in RTHeapMap__DoWalkRef (t=0x100e0f9f0, a=0x100084a48, v=0x100e20018) at ../src/runtime/common/RTHeapMap.m3:57 #5 0x0000000100034f21 in RTHeapMap__WalkRef (h=0x2018, v=0x100e20010) at ../src/runtime/common/RTHeapMap.m3:47 #6 0x000000010003b8dc in RTCollector__SanityCheck (self=0x100e20000) at ../src/runtime/common/RTCollector.m3:1660 #7 0x000000010003b618 in RTCollector__After (self=0x100e0fad0) at ../src/runtime/common/RTCollector.m3:1630 #8 0x0000000100035d35 in RTHeapRep__InvokeMonitors (before=0 '\0') at ../src/runtime/common/RTHeapRep.m3:59 #9 0x0000000100039305 in RTCollector__CollectSomeInStateFive () at ../src/runtime/common/RTCollector.m3:984 #10 0x000000010003856e in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:725 #11 0x000000010003820f in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #12 0x0000000100033d73 in RTAllocator__AllocTraced (dataSize=0, dataAlignment=8216, thread=0x8) at ../src/runtime/common/RTAllocator.m3:368 #13 0x0000000100033692 in RTAllocator__GetOpenArray (def=0x200026, s=0x100087898) at ../src/runtime/common/RTAllocator.m3:297 #14 0x00000001000329b2 in RTHooks__AllocateOpenArray (defn=0x100f2d468, s=0x100087898) at ../src/runtime/common/RTAllocator.m3:144 #15 0x0000000100002b32 in Main__AApply (cl=0x100e0fd80) at ../src/Main.m3:283 #16 0x0000000100050849 in ThreadPThread__RunThread (me=0x1703) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #17 0x000000010005050e in ThreadPThread__ThreadBase (param=0x100a01b00) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #18 0x00007fff84f908bf in _pthread_start () #19 0x00007fff84f93b75 in thread_start () This time - previous branch was not AllocTraced()->LongAlloc() dd On Apr 27, 2012, at 11:06 PM, Antony Hosking wrote: > Similarly, I suspect rd is corrupted on line 44 of FileRd.m3. > These all point to a collector bug. > Need to run with @M3paranoidgc to trigger the bug at collection time rather than later on when the mutator code is running. From dragisha at m3w.org Sat Apr 28 10:09:32 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 10:09:32 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: References: <42D52621-BA86-4D91-BFF3-27C0B4D76B31@m3w.org> <2C0FF078-178D-4B7E-B75A-82B08BE6C859@gmail.com> Message-ID: <6B6C6981-55E6-45ED-B2A6-E86A0853A23C@m3w.org> With paranoidgc errors are happening in/after AllocTraced() calls happening after AllocTraced() going short route. But not all happen here. I caught few in FileRd.Init(), again. On Apr 28, 2012, at 10:02 AM, Dragi?a Duri? wrote: > r -tests read,alloc @M3paranoidgc > Starting program: /Users/dragisha/m3/thread/AMD64_DARWIN/threadtest -tests read,alloc @M3paranoidgc > ... > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x00000000001ffff8 > [Switching to process 4249 thread 0x1703] > 0x000000010003bba1 in RTCollector__RefSanityCheck (v=Cannot access memory at address 0xffffffffffffffa7 > ) at ../src/runtime/common/RTCollector.m3:1702 > 1702 tc := h.typecode; -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 28 11:10:42 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Apr 2012 09:10:42 +0000 Subject: [M3devel] ProcessEachStack duplicates StopWorld/StartWorld? Message-ID: Tony, can ProcessEachStack not have all the stop/start code duplicated and instead look more like: StopWorld act := me.next; WHILE act # me DO ProcessOther(act) act := act.next; END StartWorld ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 28 11:29:11 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 11:29:11 +0200 Subject: [M3devel] ProcessEachStack duplicates StopWorld/StartWorld? In-Reply-To: References: Message-ID: I think it can. I've fixed that loop also, just to be sure :). On Apr 28, 2012, at 11:10 AM, Jay K wrote: > Tony, can ProcessEachStack not have all the stop/start code > duplicated and instead look more like: > > > StopWorld > act := me.next; > WHILE act # me DO > ProcessOther(act) > act := act.next; > END > StartWorld > > > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 28 15:14:55 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Apr 2012 15:14:55 +0200 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> Message-ID: <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> Mika said it does not happen with user threads. But he also said he is using pm3 mostly? So question is - did he run it with cm3, any version, with user threads. What are build parameters for cm3 with user threads? On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > That means it is even more serious. > Can we verify that it only happens with pthread threading? > > Sent from my iPad > > On Apr 28, 2012, at 1:49 AM, Dragi?a Duri? wrote: > >> It's not only AMD64_* if it's any consolation: :) From mika at async.caltech.edu Sat Apr 28 18:50:38 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 28 Apr 2012 09:50:38 -0700 Subject: [M3devel] Mika's thread test, -tests read In-Reply-To: <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> Message-ID: <20120428165038.E59451A205B@async.async.caltech.edu> Yes I have done it with user threads on CM3. (BTW, that is the configuration I always use on Darwin and Linux for "work".) There are a few ways of doing the configuration. The main thing is that the file m3-libs/m3core/src/thread/m3makefile contains the code >>> include_dir ("Common") if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") include_dir ("WIN32") else if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) include_dir("PTHREAD") else include_dir (OS_TYPE) end end <<< NO_USER_THREADS and USE_PTHREADS come from the config file. Mika =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Mika said it does not happen with user threads. But he also said he is = >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = >version, with user threads. > >What are build parameters for cm3 with user threads?=20 > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > >> That means it is even more serious. >> Can we verify that it only happens with pthread threading? >>=20 >> Sent from my iPad >>=20 >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > wrote: >>=20 >>> It's not only AMD64_* if it's any consolation: :) From jay.krell at cornell.edu Sun Apr 29 01:59:47 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Apr 2012 23:59:47 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <20120428165038.E59451A205B@async.async.caltech.edu> References: , <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com>, <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org>, , , <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com>, <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org>, <20120428165038.E59451A205B@async.async.caltech.edu> Message-ID: To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. - Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sun Apr 29 19:40:51 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 29 Apr 2012 18:40:51 +0100 (BST) Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: Message-ID: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> Iconic Modula-3 threads would be user-level transparent threads of machine threads, but then you would need threading system to cope with. I believe that current system is OK respect PTHREADS as much as is, this is specially true if there isn't one application that use threads of machine-level likely easier than other application users of them (see for example cvsup), cvsup has strong reliance on network idle times to decompress and use disk files to continue downloading over a two channel communication space, if you have server-side SMP-threads, then it's not easier to use them accordingly, because you still may have lower latencies queuing them and proportionately them to your users (your system will queue them as FIFO), but while your threads might finish connection faster, other user-level threads might need them more time to finish so they will be locked until (due network considerations and system dequeuing) clients get their messages off-time also, which is not fair if you are downloading small bits of code after other's longer chunks of code. I learned this while downloading with user-level threads and faster than with network same conditions and same machine with p-threads'ed systems longer finish time. Now this is counter-wise effect, as I got this while downloading from user-level thread system. Thanks in advance Thanks in advance http://modula3.elegosoft.com/cm3/ --- El s?b, 28/4/12, Jay K escribi?: De: Jay K Asunto: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? Para: "Mika Nystrom" , dragisha at m3w.org CC: "m3devel" Fecha: s?bado, 28 de abril, 2012 18:59 To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. ?- Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 29 23:01:39 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Apr 2012 21:01:39 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <26C159EB-EDC6-453C-A8EE-2F1AAAF0E170@gmail.com> References: <57E6768C-1501-461E-8A17-F947BC522BB3@gmail.com> <03CA8352-CBAB-4279-8B8F-403ADE6E1621@m3w.org> <2C84D5F9-A519-4C91-A837-A16AAAB7C9B9@gmail.com> <8A850D5B-BAE1-4BEE-AB98-1A6ED97B568D@m3w.org> <20120428165038.E59451A205B@async.async.caltech.edu> , <26C159EB-EDC6-453C-A8EE-2F1AAAF0E170@gmail.com> Message-ID: Ok, I can't argue with that. - Jay CC: mika at async.caltech.edu; dragisha at m3w.org; m3devel at elegosoft.com From: antony.hosking at gmail.com Subject: Re: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? Date: Sat, 28 Apr 2012 19:58:28 -0500 To: jay.krell at cornell.edu I'm just being conservative. Let's fix bugs before refactoring further. Sent from my iPad On Apr 28, 2012, at 6:59 PM, Jay K wrote: To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option. I understand that would inhibit inlining via function pointers/dynamic linking. Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems. Taking/releasing a lock would always incur a function call through a pointer. As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything. I could do the work, but I believe so far that Tony doesn't want it. - Jay > To: dragisha at m3w.org > Date: Sat, 28 Apr 2012 09:50:38 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Mika's thread test, -tests read > > > Yes I have done it with user threads on CM3. > > (BTW, that is the configuration I always use on Darwin and Linux for "work".) > > There are a few ways of doing the configuration. The main thing is that the > file > > m3-libs/m3core/src/thread/m3makefile > > contains the code >>> > > include_dir ("Common") > > > if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386") > include_dir ("WIN32") > else > if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET}) > include_dir("PTHREAD") > else > include_dir (OS_TYPE) > end > end > > <<< > > NO_USER_THREADS and USE_PTHREADS come from the config file. > > Mika > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Mika said it does not happen with user threads. But he also said he is = > >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any = > >version, with user threads. > > > >What are build parameters for cm3 with user threads?=20 > > > >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote: > > > >> That means it is even more serious. > >> Can we verify that it only happens with pthread threading? > >>=20 > >> Sent from my iPad > >>=20 > >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 = > > wrote: > >>=20 > >>> It's not only AMD64_* if it's any consolation: :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Apr 29 23:11:36 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 29 Apr 2012 17:11:36 -0400 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <20120429211136.GA31736@topoi.pooq.com> On Sun, Apr 29, 2012 at 06:40:51PM +0100, Daniel Alejandro Benavides D. wrote: > (see for example cvsup), cvsup has strong reliance on network idle > times Speaking of cvsup, I seem to remember it stopped working, perhaps because of thread implementatino problems. Is it back in order yet? -- hendrik From jay.krell at cornell.edu Sun Apr 29 23:20:58 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Apr 2012 21:20:58 +0000 Subject: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? In-Reply-To: <20120429211136.GA31736@topoi.pooq.com> References: , <1335721251.57755.YahooMailClassic@web29701.mail.ird.yahoo.com>, <20120429211136.GA31736@topoi.pooq.com> Message-ID: We fixed it a long time ago. The problem was: Usually fork() is followed very soon by exec(). i.e. the way Posix programs (processes) often run sub-programs (processes) is via fork and exec. This is ok. No problem. However there is another pattern of use of fork where "servers" call fork for each "client". They don't exec. It is something like creating a thread. Except that everything is read-only/copy-on-write, not really shared. This is useful if servers have an expensive initialization, and don't need to share per-client. Cvsup does that. When fork is not followed by exec, whatever Modula-3 user threads existed in the "parent" process, still exist in the "child" process. The same is NOT true with pthreads. cvsup depended on the threads all surviving fork. We fixed cvsup to recreate its threads in the child process, and to fix user threads to NOT have threads survive fork, except the one calling fork. This highlighted other problems -- the existance of and possible need to use pthread_atfork. I'm not really explaining it all, but mostly. Look up pthread_atfork. - Jay > Date: Sun, 29 Apr 2012 17:11:36 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] swaping user threads for kernel threads w/o rebuilding everything? > > On Sun, Apr 29, 2012 at 06:40:51PM +0100, Daniel Alejandro Benavides D. wrote: > > (see for example cvsup), cvsup has strong reliance on network idle > > times > > Speaking of cvsup, I seem to remember it stopped working, perhaps > because of thread implementatino problems. Is it back in order yet? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 29 23:49:22 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 29 Apr 2012 16:49:22 -0500 Subject: [M3devel] Downsides of Modula-3 ? In-Reply-To: <20120427174948.9BB191A205B@async.async.caltech.edu> References: <1335495004.88370.YahooMailClassic@web29703.mail.ird.yahoo.com> <20120427030228.B46BC1A205B@async.async.caltech.edu> <9456A300-5A09-4493-9965-025B76DD074B@m3w.org> <20120427171341.0D83E1A205E@async.async.caltech.edu> <20120427174948.9BB191A205B@async.async.caltech.edu> Message-ID: <4F9DB762.3030608@lcwb.coop> On 04/27/2012 12:49 PM, Mika Nystrom wrote: > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >> I do not doubt they are created. Probably not an issue with 3 threads = >> here, 3 threads there, but it can be if one relies on "must be created = >> after some arbitrary time" in any synchronization. I did, and SRC people = >> did, at least in two places. I just don't see it as a good practice. > > Yes I have had that bug in my programs a few times. > > But to be really fair it's not that you're assuming that another > thread is created by a certain time but you're assuming that it has > done something by the time the first thread needs to do something else. > In the examples of the sort you describe it is usually that the newly > created thread has "had time to initialize" (in some way). My bug with > this was of this nature: > > thread A: > > ... Thread.Fork(b)... wait... LOCK(b.mu) > > Thread B: > > ... self.mu := NEW(MUTEX) ... > > Oops! works on some threading implementations (user threads). > Instant segfault on others! As I recall, this is the reason Thread.T <: MUTEX. Otherwise, there would be chicken-egg cases like this where you need a mutex to protect the allocation of a mutex and have no dependable way to get one. > > Have fun with the thread tester. It doesn't find any problems with > user threads. > > I should probably have dug into the pthreads myself long ago but it's > always so far down the todo list, and all my CM3 installations use user > threads by necessity. If you can improve the pthreads I think it would > make me much happier about CM3 in general. I still use PM3 as much as > possible... > > Mika > > >> >> BTW, your test is excellent stress machine. My laptops hate it, = >> probably, till now :). Right now I am focused on an allocation race = >> issue and I hope to fix it in few hours/a day. >> >> On Apr 27, 2012, at 7:13 PM, Mika Nystrom wrote: >> >>> =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>> ... >>>> I am reading your source code just now. And one thing caught my eye: = >> =3D >>>> "Each type of thread starts by sleeping for a while, to give the = >> other =3D >>>> threads a chance to be created." Does not look like any guarantee to = >> me, =3D >>>> not in threaded application.=3D20=3D >>> =20 >>> If the program prints "running" then all threads have been created. >>> =20 >>> It eventually prints "running". >>> =20 >>> Therefore all threads are created. >>> =20 >>> --- >>> =20 >>> The things wrong with CM3's pthreads threading are NOT subtle. >>> The runtime completely freezes up, ctrl-C stops working, and other >>> such things. >>> =20 >>> Mika >