From rodney.bates at wichita.edu Thu Jul 3 01:33:21 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 02 Jul 2008 18:33:21 -0500 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 Message-ID: <486C1041.4060004@wichita.edu> Using a freshly installed cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails with: === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ --- building in LINUXLIBC6 --- Fatal Error: bad version stamps: RTArgs.m3 RTArgs.m3: missing imported type: _tf3a6cedc RTArgs.m3: missing imported type: _t8b2831d7 *** execution of cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' failed *** Sounds like another bootstrapping problem of some kind. Shouldn't the latest snapshot work on current cvs? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Thu Jul 3 10:16:41 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Jul 2008 10:16:41 +0200 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 In-Reply-To: <486C1041.4060004@wichita.edu> References: <486C1041.4060004@wichita.edu> Message-ID: <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Using a freshly installed > cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, > and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails with: > > === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === > +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V > ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in LINUXLIBC6 --- > > Fatal Error: bad version stamps: RTArgs.m3 > > RTArgs.m3: missing imported type: _tf3a6cedc > RTArgs.m3: missing imported type: _t8b2831d7 > *** execution of cm3 -build -override > -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 > .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' > failed *** > > Sounds like another bootstrapping problem of some kind. Shouldn't the latest > snapshot work on current cvs? As the snapshot archives are built every night from a current CVS checkout, this should surely be the case. I bet you've got some old derived files in your workspace and didn't clear them properly. Try ./scripts/do-cm3-all.sh realclean. 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 rodney.bates at wichita.edu Fri Jul 4 18:45:53 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 04 Jul 2008 11:45:53 -0500 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 In-Reply-To: <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> References: <486C1041.4060004@wichita.edu> <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> Message-ID: <486E53C1.7020907@wichita.edu> Ah, realclean. I tend to forget about that when I think I'm just doing a fresh build. Thanks, that fixed that problem. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> Using a freshly installed >> cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, >> and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails >> with: >> >> === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === >> +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' >> -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V >> ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ >> --- building in LINUXLIBC6 --- >> >> Fatal Error: bad version stamps: RTArgs.m3 >> >> RTArgs.m3: missing imported type: _tf3a6cedc >> RTArgs.m3: missing imported type: _t8b2831d7 >> *** execution of cm3 -build -override >> -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 >> .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' >> failed *** >> >> Sounds like another bootstrapping problem of some kind. Shouldn't the >> latest >> snapshot work on current cvs? > > > As the snapshot archives are built every night from a current CVS > checkout, this should surely be the case. I bet you've got some > old derived files in your workspace and didn't clear them > properly. Try ./scripts/do-cm3-all.sh realclean. > > Olaf -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Fri Jul 18 19:21:57 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 18 Jul 2008 17:21:57 +0000 (GMT) Subject: [M3devel] Luca Cardelli Interview and video tape resources Message-ID: <484587.75213.qm@web27102.mail.ukl.yahoo.com> Dear all, check the link http://www.computerworld.com.au/index.php/id;1422447371;fp;;fpid; Besides, does anyone know if the video tapes of the research reports (including the one of the language release) is available for download or external lend of a library? I found this one from http://wally.rit.edu/pubs/guides/csvideo.html? : OPERATING SYSTEMS & LANGUAGES MRC VH 701K Donahue, Jim. Modula-3 . UVC, 1991. Lecture by Jim Donahue, Olivetti Research California. Summarizes the joint work of ORC and DEC's Systems Research Center to design Modula-3, a new systems programming language descending from Mesa, Modula-2, and Modula 2+. Describes the principles that drove the language design and discusses the most important features of the language, emphasizing the type system, its most innovative feature. Ends with a Q&A session. the above can be checked on: http://albert.rit.edu/record=b1251585 also in (Hong Kong): http://lib.cityu.edu.hk/record=b1165121 ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 29 22:17:35 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 29 Jul 2008 16:17:35 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week Message-ID: <488F4292.1E75.00D7.1@scires.com> Hi: I've been using cm3 to develop software I am delivering this week to a customer. During the acceptance testing, we've run into a problem that I have not been able to solve. I am hoping someone in the cm3 community can help. I need to solve this problem ASAP this week. This problem is easily reproduced using the "formsedit" program. The problem is with the TypeIn and TypeScript FormsVBT elements used in my program. Since formsedit uses these, you can easily reproduce the problem. Click with the mouse to move the insertion point somewhere in the text. Observe that the cursor moves to that point. Now, use the left arrow key to move the insertion point a few characters to the left. Then, type a few characters. Observe that the first character you type shows up at the place where you initially moved the cursor with the mouse, while the remaining characters show up at the place where you moved the cursor via the left-arrow key. This behavior is wrong. The first character you type should be at the current insertion point, not at the one from the mouse move. I'm sure the fix is easy, but I haven't been able to locate it yet. It probably has to do with the internal idea of the insertion point not getting updated properly. Note that the cursor on the screen is in the right spot, it's just that the first character gets inserted into the TypeIn or TypeScript in the wrong place (i.e., it is put at the place from the mouse move, not from the last arrow key move). Any assistance you can provide is very much appreciated and will go a long way toward keeping Modula-3 use alive and well for this project. If we can't fix this one, the customers will want to re-code everything in some Microsoft language, probably C++ or C#. I also have one other strange anomaly, but it is less of an issue at the moment. On a Dell M4300 laptop at 1920x1200 resolution, all pixmaps are getting stretched vertically. Text seems to be fine as do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out of proportion. This problem has not happened on all other platforms I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at 1400x1050, etc.). Any ideas on what could be the issue? I know that 1920x1200 is a strange resolution, but it is the native resolution for the M4300 laptop computer that the customer is using. I checked and the computer is set for 96dpi (normal). Perhaps there is some Trestle setting that I need to tweak on this platform, or perhaps there is a bug that needs fixing. Regards, Randy Coleburn Senior Systems Engineer Scientific Research Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 29 23:04:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Jul 2008 22:04:53 +0100 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <488F4292.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> Message-ID: <24C18663-4CA5-4DBA-AC2E-240FBBD6EF47@cs.purdue.edu> Hmm, do we have any Trestle gurus these days? On Jul 29, 2008, at 9:17 PM, Randy Coleburn wrote: > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a problem > that I have not been able to solve. I am hoping someone in the cm3 > community can help. I need to solve this problem ASAP this week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily reproduce > the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. > > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen is > in the right spot, it's just that the first character gets inserted > into the TypeIn or TypeScript in the wrong place (i.e., it is put at > the place from the mouse move, not from the last arrow key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to re- > code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is > using. I checked and the computer is set for 96dpi (normal). > Perhaps there is some Trestle setting that I need to tweak on this > platform, or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jul 30 05:46:28 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 30 Jul 2008 03:46:28 +0000 (GMT) Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <24C18663-4CA5-4DBA-AC2E-240FBBD6EF47@cs.purdue.edu> Message-ID: <714610.11568.qm@web27104.mail.ukl.yahoo.com> Dear all: I have some (user point of view) experience with trestle and as I see in a kubuntu 8.04 box here with almost up to date cm3 environment, I have not seen in formsedit the bug you report (at least in the source code box), and looking where is actually used TypeInVBT, it's not actually imported by any interface, see (on cm3ide): http://localhost:3800/public/ui/src/split/TypeInVBT.i3/ but it does TypeinVBT http://localhost:3800/public/vbtkit/src/etext/TypeinVBT.i3/ imported by several clients (including vbtkit). If I guess rigth you migth be using that TypeinVBT. As I say works fine (with this linux box in the formsedit program on the source code box). So I think if you have tested this software with a previous version of Trestle and it worked fine, then I think the? changes made in the cm3 sources have affected the mentioned Interface, so it's easier to catch the bug, but if you haven't tested with the previous version of Trestle (is not possible, or the behaviour is the same with both versions of Trestle), then could be some ?? win32 dependant interface causing the bug. Could you make that comparison with of both Trestle implemenations using formsedit? I can give it a try (first, setting a working win32 box with cm3) and see what happens with formsedit (or if you have a win32 box I can point an url of m3browser or cm3ide) to get an idea of what happens deeping in the sources of both implementations (from formsedit source). Let me know if this is useful. Good luck.? --- El mar, 29/7/08, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week Para: "Randy Coleburn" CC: m3devel at elegosoft.com, m3-support at elego.de Fecha: martes, 29 julio, 2008 4:04 Hmm, do we have any Trestle gurus these days? On Jul 29, 2008, at 9:17 PM, Randy Coleburn wrote: Hi: ? I've been using cm3 to develop software I am delivering this week to a customer.? During the acceptance testing, we've run into a problem that I have not been able to solve.? I am hoping someone in the cm3 community can help.? I need to solve this problem ASAP this week. ? This problem is easily reproduced using the "formsedit" program. ? The problem is with the?TypeIn and TypeScript FormsVBT elements used in my program.? Since formsedit uses these, you can easily reproduce the problem. ? Click with the mouse to move the insertion point somewhere in the text.? Observe that the cursor moves to that point.? Now, use the left arrow key to move the insertion point a few characters to the left.? Then, type a few characters.? Observe that the first character you type shows up at the place where you initially moved the cursor with the mouse, while the remaining characters show up at the place where you moved the cursor via the left-arrow key.? This behavior is wrong.? The first character you type should be at the current insertion point, not at the one from the mouse move. ? I'm sure the fix is easy, but I haven't been able to locate it yet.? It probably has to do with the internal idea of the insertion point not getting updated properly.? Note that the cursor on the screen is in the right spot, it's just that the first character gets inserted into the TypeIn or TypeScript in the wrong place (i.e., it is put at the place from the mouse move, not from the last arrow key move). ? Any assistance you can provide is very much appreciated and will go a long way toward keeping Modula-3 use alive and well for this project.? If we can't fix this one, the customers will want to re-code everything in some Microsoft language, probably C++ or C#. ? I also have one other strange anomaly, but it is less of an issue at the moment.? On a Dell M4300 laptop at 1920x1200 resolution, all pixmaps are getting stretched vertically.? Text seems to be fine as do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out of proportion.? This problem has not happened on all other platforms I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at 1400x1050, etc.).? Any ideas on what could be the issue?? I know that 1920x1200 is a strange resolution, but it is the native resolution for the M4300 laptop computer that the customer is using.? I checked and the computer is set for 96dpi (normal).? Perhaps there is some Trestle setting that I need to tweak on this platform, or perhaps there is a bug that needs fixing. ? Regards, Randy Coleburn Senior Systems Engineer Scientific Research Corporation ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 30 08:24:11 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 30 Jul 2008 08:24:11 +0200 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <488F4292.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> Message-ID: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Quoting Randy Coleburn : > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a > problem that I have not been able to solve. I am hoping someone in > the cm3 community can help. I need to solve this problem ASAP this > week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily > reproduce the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. Randy, I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able to reproduce the problem on FreeBSD 6.3. Does the problem show up on all platforms you are working on? Which are these? Are there any local modifications to the libraries which I may not have? If it occurs only on Unix, it may be possible that a weird window manager interferes with the event delivery; otherwise I've got no good idea. If on Unix, you/we could perhaps test the behaviour on a different (remote) X display? Please provide more data about the problem context and how to reproduce it. Regards, Olaf > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen > is in the right spot, it's just that the first character gets > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > is put at the place from the mouse move, not from the last arrow > key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to > re-code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is using. > I checked and the computer is set for 96dpi (normal). Perhaps > there is some Trestle setting that I need to tweak on this platform, > or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation > -- 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 rodney.bates at wichita.edu Wed Jul 30 19:12:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 30 Jul 2008 12:12:43 -0500 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Message-ID: <4890A10B.4050701@wichita.edu> I can't reproduce it in LINUXLIBC6 either. Olaf Wagner wrote: > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 31 04:31:01 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 30 Jul 2008 22:31:01 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Message-ID: <4890EB9C.1E75.00D7.1@scires.com> Hi Olaf, Daniel, Rodney, et al: Thanks for your responses so far. Sorry for the delay in replying, but our email server has been offline for nearly 24-hours. There were some severe electrical storms that took down both redundant power systems for our email system. Hope I have not missed any of your replies. Right now, I am delivering the software on Windows XP using SP2 or greater. I have not tried to see if this problem also occurs on Unix. I don't have ready access to a unix system from my current location. So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any event, it is a real problem for me. As for the pixmap stretching problem, I have tested various resolutions on the customer's computer. Unfortunately, the customer demands that the display resolution stay at the 1920x1200. 1920x1200=pixmap stretch problem 1680x1050=pixmap stretch problem 1440x900=no problem 1024x768=no problem Regards, Randy >>> Olaf Wagner 7/30/2008 2:24 AM >>> Quoting Randy Coleburn : > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a > problem that I have not been able to solve. I am hoping someone in > the cm3 community can help. I need to solve this problem ASAP this > week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily > reproduce the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. Randy, I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able to reproduce the problem on FreeBSD 6.3. Does the problem show up on all platforms you are working on? Which are these? Are there any local modifications to the libraries which I may not have? If it occurs only on Unix, it may be possible that a weird window manager interferes with the event delivery; otherwise I've got no good idea. If on Unix, you/we could perhaps test the behaviour on a different (remote) X display? Please provide more data about the problem context and how to reproduce it. Regards, Olaf > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen > is in the right spot, it's just that the first character gets > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > is put at the place from the mouse move, not from the last arrow > key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to > re-code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is using. > I checked and the computer is set for 96dpi (normal). Perhaps > there is some Trestle setting that I need to tweak on this platform, > or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Jul 31 15:33:12 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 31 Jul 2008 08:33:12 -0500 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4890EB9C.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> Message-ID: <4891BF18.8000905@wichita.edu> Which variant of the M3 Windows target are you using? I don't have any of them built right now. Randy Coleburn wrote: > Hi Olaf, Daniel, Rodney, et al: > > Thanks for your responses so far. Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours. There were some > severe electrical storms that took down both redundant power systems for > our email system. Hope I have not missed any of your replies. > > Right now, I am delivering the software on Windows XP using SP2 or > greater. I have not tried to see if this problem also occurs on Unix. > I don't have ready access to a unix system from my current location. > > So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any > event, it is a real problem for me. > > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer. Unfortunately, the customer demands that > the display resolution stay at the 1920x1200. > 1920x1200=pixmap stretch problem > 1680x1050=pixmap stretch problem > 1440x900=no problem > 1024x768=no problem > > Regards, > Randy > > >>> Olaf Wagner 7/30/2008 2:24 AM >>> > Quoting Randy Coleburn : > > > Hi: > > > > I've been using cm3 to develop software I am delivering this week to > > a customer. During the acceptance testing, we've run into a > > problem that I have not been able to solve. I am hoping someone in > > the cm3 community can help. I need to solve this problem ASAP this > > week. > > > > This problem is easily reproduced using the "formsedit" program. > > > > The problem is with the TypeIn and TypeScript FormsVBT elements used > > in my program. Since formsedit uses these, you can easily > > reproduce the problem. > > > > Click with the mouse to move the insertion point somewhere in the > > text. Observe that the cursor moves to that point. Now, use the > > left arrow key to move the insertion point a few characters to the > > left. Then, type a few characters. Observe that the first > > character you type shows up at the place where you initially moved > > the cursor with the mouse, while the remaining characters show up at > > the place where you moved the cursor via the left-arrow key. This > > behavior is wrong. The first character you type should be at the > > current insertion point, not at the one from the mouse move. > > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > > > I'm sure the fix is easy, but I haven't been able to locate it yet. > > It probably has to do with the internal idea of the insertion point > > not getting updated properly. Note that the cursor on the screen > > is in the right spot, it's just that the first character gets > > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > > is put at the place from the mouse move, not from the last arrow > > key move). > > > > Any assistance you can provide is very much appreciated and will go > > a long way toward keeping Modula-3 use alive and well for this > > project. If we can't fix this one, the customers will want to > > re-code everything in some Microsoft language, probably C++ or C#. > > > > I also have one other strange anomaly, but it is less of an issue at > > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > > pixmaps are getting stretched vertically. Text seems to be fine as > > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > > of proportion. This problem has not happened on all other platforms > > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > > 1400x1050, etc.). Any ideas on what could be the issue? I know > > that 1920x1200 is a strange resolution, but it is the native > > resolution for the M4300 laptop computer that the customer is using. > > I checked and the computer is set for 96dpi (normal). Perhaps > > there is some Trestle setting that I need to tweak on this platform, > > or perhaps there is a bug that needs fixing. > > > > Regards, > > Randy Coleburn > > Senior Systems Engineer > > Scientific Research Corporation > > > > > > -- > 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 > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 31 17:51:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jul 2008 11:51:28 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4891BF18.8000905@wichita.edu> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> Message-ID: <4891A737.1E75.00D7.1@scires.com> Rodney: I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied). Michel Dagenais suggested that if the problem does not reproduce on Linux, that it might have to do with how Windows reports character events. He thought a Filter VBT may exist somewhere that would aid in debugging by printing method calls before propagating them to father/son. This filter VBT would be inserted at different places in the VBT tree to get tracing information. Are you familiar with something like this? As for the pixmaps, Michel suggests increasing the resolution of the original pixmap to help alleviate problems with upscaling. I may try this, but of course, FormsVBT uses a lot of pixmap resources, for example, radio, boolean, checkmark, numeric, etc all use pixmaps. Regards, Randy >>> "Rodney M. Bates" 7/31/2008 9:33 AM >>> Which variant of the M3 Windows target are you using? I don't have any of them built right now. Randy Coleburn wrote: > Hi Olaf, Daniel, Rodney, et al: > > Thanks for your responses so far. Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours. There were some > severe electrical storms that took down both redundant power systems for > our email system. Hope I have not missed any of your replies. > > Right now, I am delivering the software on Windows XP using SP2 or > greater. I have not tried to see if this problem also occurs on Unix. > I don't have ready access to a unix system from my current location. > > So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any > event, it is a real problem for me. > > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer. Unfortunately, the customer demands that > the display resolution stay at the 1920x1200. > 1920x1200=pixmap stretch problem > 1680x1050=pixmap stretch problem > 1440x900=no problem > 1024x768=no problem > > Regards, > Randy > > >>> Olaf Wagner 7/30/2008 2:24 AM >>> > Quoting Randy Coleburn : > > > Hi: > > > > I've been using cm3 to develop software I am delivering this week to > > a customer. During the acceptance testing, we've run into a > > problem that I have not been able to solve. I am hoping someone in > > the cm3 community can help. I need to solve this problem ASAP this > > week. > > > > This problem is easily reproduced using the "formsedit" program. > > > > The problem is with the TypeIn and TypeScript FormsVBT elements used > > in my program. Since formsedit uses these, you can easily > > reproduce the problem. > > > > Click with the mouse to move the insertion point somewhere in the > > text. Observe that the cursor moves to that point. Now, use the > > left arrow key to move the insertion point a few characters to the > > left. Then, type a few characters. Observe that the first > > character you type shows up at the place where you initially moved > > the cursor with the mouse, while the remaining characters show up at > > the place where you moved the cursor via the left-arrow key. This > > behavior is wrong. The first character you type should be at the > > current insertion point, not at the one from the mouse move. > > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > > > I'm sure the fix is easy, but I haven't been able to locate it yet. > > It probably has to do with the internal idea of the insertion point > > not getting updated properly. Note that the cursor on the screen > > is in the right spot, it's just that the first character gets > > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > > is put at the place from the mouse move, not from the last arrow > > key move). > > > > Any assistance you can provide is very much appreciated and will go > > a long way toward keeping Modula-3 use alive and well for this > > project. If we can't fix this one, the customers will want to > > re-code everything in some Microsoft language, probably C++ or C#. > > > > I also have one other strange anomaly, but it is less of an issue at > > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > > pixmaps are getting stretched vertically. Text seems to be fine as > > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > > of proportion. This problem has not happened on all other platforms > > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > > 1400x1050, etc.). Any ideas on what could be the issue? I know > > that 1920x1200 is a strange resolution, but it is the native > > resolution for the M4300 laptop computer that the customer is using. > > I checked and the computer is set for 96dpi (normal). Perhaps > > there is some Trestle setting that I need to tweak on this platform, > > or perhaps there is a bug that needs fixing. > > > > Regards, > > Randy Coleburn > > Senior Systems Engineer > > Scientific Research Corporation > > > > > > -- > 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 > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 31 18:44:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jul 2008 18:44:49 +0200 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4891A737.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> <4891A737.1E75.00D7.1@scires.com> Message-ID: <20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com> Quoting Randy Coleburn : > Rodney: > > I am using Windows XP Professional, Service Pack 2 (on some systems, > Service Pack 3 is applied). Hi Randy, I just tried formsedit on exactly this system (XP professional, SP2) in my virtual machine, and wasn't able to see any fault wrt. cursor processing and typing, too. I checked-out and compiled all the latest sources of the relevant gui packages (ui, vbtkit, formsvbt etc.), but that didn't make any difference (though some changes had been applied). For me it just seems to work correctly. It may be of interest though that some months ago when I was last working on this system for the regression tests, I applied all existing Microsoft patches; but you've done that probably, too. I've got no idea about the pixmap problem, too. As long as nobody else is able to reproduce the problem it will remain difficult to analyze this problem. Sorry that I cannot be of more help, Olaf PS: Are you sure that you are really using exactly the current CM3 gui libraries, and not some adapted or modified stuff from an older release? > Michel Dagenais suggested that if the problem does not reproduce on > Linux, that it might have to do with how Windows reports character > events. He thought a Filter VBT may exist somewhere that would aid in > debugging by printing method calls before propagating them to > father/son. This filter VBT would be inserted at different places in > the VBT tree to get tracing information. Are you familiar with > something like this? > > As for the pixmaps, Michel suggests increasing the resolution of the > original pixmap to help alleviate problems with upscaling. I may try > this, but of course, FormsVBT uses a lot of pixmap resources, for > example, radio, boolean, checkmark, numeric, etc all use pixmaps. > > Regards, > Randy > >>>> "Rodney M. Bates" 7/31/2008 9:33 AM >>> > Which variant of the M3 Windows target are you using? I don't have > any > of them built right now. > > Randy Coleburn wrote: >> Hi Olaf, Daniel, Rodney, et al: >> >> Thanks for your responses so far. Sorry for the delay in replying, > but >> our email server has been offline for nearly 24-hours. There were > some >> severe electrical storms that took down both redundant power systems > for >> our email system. Hope I have not missed any of your replies. >> >> Right now, I am delivering the software on Windows XP using SP2 or >> greater. I have not tried to see if this problem also occurs on > Unix. >> I don't have ready access to a unix system from my current location. >> >> So it is perhaps a Windows-only problem with Trestle/FormsVBT. In > any >> event, it is a real problem for me. >> >> As for the pixmap stretching problem, I have tested various > resolutions >> on the customer's computer. Unfortunately, the customer demands that > >> the display resolution stay at the 1920x1200. >> 1920x1200=pixmap stretch problem >> 1680x1050=pixmap stretch problem >> 1440x900=no problem >> 1024x768=no problem >> >> Regards, >> Randy >> >> >>> Olaf Wagner 7/30/2008 2:24 AM >>> >> Quoting Randy Coleburn : >> >> > Hi: >> > >> > I've been using cm3 to develop software I am delivering this week > to >> > a customer. During the acceptance testing, we've run into a >> > problem that I have not been able to solve. I am hoping someone > in >> > the cm3 community can help. I need to solve this problem ASAP > this >> > week. >> > >> > This problem is easily reproduced using the "formsedit" program. >> > >> > The problem is with the TypeIn and TypeScript FormsVBT elements > used >> > in my program. Since formsedit uses these, you can easily >> > reproduce the problem. >> > >> > Click with the mouse to move the insertion point somewhere in the > >> > text. Observe that the cursor moves to that point. Now, use the > >> > left arrow key to move the insertion point a few characters to the > >> > left. Then, type a few characters. Observe that the first >> > character you type shows up at the place where you initially moved > >> > the cursor with the mouse, while the remaining characters show up > at >> > the place where you moved the cursor via the left-arrow key. > This >> > behavior is wrong. The first character you type should be at the > >> > current insertion point, not at the one from the mouse move. >> >> Randy, >> >> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't > able >> to reproduce the problem on FreeBSD 6.3. >> >> Does the problem show up on all platforms you are working on? >> Which are these? >> >> Are there any local modifications to the libraries which I may not >> have? >> >> If it occurs only on Unix, it may be possible that a weird window >> manager interferes with the event delivery; otherwise I've got no >> good idea. If on Unix, you/we could perhaps test the behaviour >> on a different (remote) X display? >> >> Please provide more data about the problem context and how to >> reproduce it. >> >> Regards, >> >> Olaf >> >> > I'm sure the fix is easy, but I haven't been able to locate it > yet. >> > It probably has to do with the internal idea of the insertion > point >> > not getting updated properly. Note that the cursor on the screen > >> > is in the right spot, it's just that the first character gets >> > inserted into the TypeIn or TypeScript in the wrong place (i.e., > it >> > is put at the place from the mouse move, not from the last arrow > >> > key move). >> > >> > Any assistance you can provide is very much appreciated and will > go >> > a long way toward keeping Modula-3 use alive and well for this >> > project. If we can't fix this one, the customers will want to >> > re-code everything in some Microsoft language, probably C++ or > C#. >> > >> > I also have one other strange anomaly, but it is less of an issue > at >> > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > >> > pixmaps are getting stretched vertically. Text seems to be fine > as >> > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched > out >> > of proportion. This problem has not happened on all other > platforms >> > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 > at >> > 1400x1050, etc.). Any ideas on what could be the issue? I know > >> > that 1920x1200 is a strange resolution, but it is the native >> > resolution for the M4300 laptop computer that the customer is > using. >> > I checked and the computer is set for 96dpi (normal). Perhaps > >> > there is some Trestle setting that I need to tweak on this > platform, >> > or perhaps there is a bug that needs fixing. >> > >> > Regards, >> > Randy Coleburn >> > Senior Systems Engineer >> > Scientific Research Corporation >> > >> >> >> >> -- >> 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 >> >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu > > -- 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 rodney.bates at wichita.edu Thu Jul 3 01:33:21 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 02 Jul 2008 18:33:21 -0500 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 Message-ID: <486C1041.4060004@wichita.edu> Using a freshly installed cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails with: === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ --- building in LINUXLIBC6 --- Fatal Error: bad version stamps: RTArgs.m3 RTArgs.m3: missing imported type: _tf3a6cedc RTArgs.m3: missing imported type: _t8b2831d7 *** execution of cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' failed *** Sounds like another bootstrapping problem of some kind. Shouldn't the latest snapshot work on current cvs? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Thu Jul 3 10:16:41 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Jul 2008 10:16:41 +0200 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 In-Reply-To: <486C1041.4060004@wichita.edu> References: <486C1041.4060004@wichita.edu> Message-ID: <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Using a freshly installed > cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, > and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails with: > > === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === > +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V > ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in LINUXLIBC6 --- > > Fatal Error: bad version stamps: RTArgs.m3 > > RTArgs.m3: missing imported type: _tf3a6cedc > RTArgs.m3: missing imported type: _t8b2831d7 > *** execution of cm3 -build -override > -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 > .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' > failed *** > > Sounds like another bootstrapping problem of some kind. Shouldn't the latest > snapshot work on current cvs? As the snapshot archives are built every night from a current CVS checkout, this should surely be the case. I bet you've got some old derived files in your workspace and didn't clear them properly. Try ./scripts/do-cm3-all.sh realclean. 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 rodney.bates at wichita.edu Fri Jul 4 18:45:53 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 04 Jul 2008 11:45:53 -0500 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 In-Reply-To: <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> References: <486C1041.4060004@wichita.edu> <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> Message-ID: <486E53C1.7020907@wichita.edu> Ah, realclean. I tend to forget about that when I think I'm just doing a fresh build. Thanks, that fixed that problem. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> Using a freshly installed >> cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, >> and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails >> with: >> >> === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === >> +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' >> -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V >> ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ >> --- building in LINUXLIBC6 --- >> >> Fatal Error: bad version stamps: RTArgs.m3 >> >> RTArgs.m3: missing imported type: _tf3a6cedc >> RTArgs.m3: missing imported type: _t8b2831d7 >> *** execution of cm3 -build -override >> -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 >> .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' >> failed *** >> >> Sounds like another bootstrapping problem of some kind. Shouldn't the >> latest >> snapshot work on current cvs? > > > As the snapshot archives are built every night from a current CVS > checkout, this should surely be the case. I bet you've got some > old derived files in your workspace and didn't clear them > properly. Try ./scripts/do-cm3-all.sh realclean. > > Olaf -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Fri Jul 18 19:21:57 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 18 Jul 2008 17:21:57 +0000 (GMT) Subject: [M3devel] Luca Cardelli Interview and video tape resources Message-ID: <484587.75213.qm@web27102.mail.ukl.yahoo.com> Dear all, check the link http://www.computerworld.com.au/index.php/id;1422447371;fp;;fpid; Besides, does anyone know if the video tapes of the research reports (including the one of the language release) is available for download or external lend of a library? I found this one from http://wally.rit.edu/pubs/guides/csvideo.html? : OPERATING SYSTEMS & LANGUAGES MRC VH 701K Donahue, Jim. Modula-3 . UVC, 1991. Lecture by Jim Donahue, Olivetti Research California. Summarizes the joint work of ORC and DEC's Systems Research Center to design Modula-3, a new systems programming language descending from Mesa, Modula-2, and Modula 2+. Describes the principles that drove the language design and discusses the most important features of the language, emphasizing the type system, its most innovative feature. Ends with a Q&A session. the above can be checked on: http://albert.rit.edu/record=b1251585 also in (Hong Kong): http://lib.cityu.edu.hk/record=b1165121 ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 29 22:17:35 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 29 Jul 2008 16:17:35 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week Message-ID: <488F4292.1E75.00D7.1@scires.com> Hi: I've been using cm3 to develop software I am delivering this week to a customer. During the acceptance testing, we've run into a problem that I have not been able to solve. I am hoping someone in the cm3 community can help. I need to solve this problem ASAP this week. This problem is easily reproduced using the "formsedit" program. The problem is with the TypeIn and TypeScript FormsVBT elements used in my program. Since formsedit uses these, you can easily reproduce the problem. Click with the mouse to move the insertion point somewhere in the text. Observe that the cursor moves to that point. Now, use the left arrow key to move the insertion point a few characters to the left. Then, type a few characters. Observe that the first character you type shows up at the place where you initially moved the cursor with the mouse, while the remaining characters show up at the place where you moved the cursor via the left-arrow key. This behavior is wrong. The first character you type should be at the current insertion point, not at the one from the mouse move. I'm sure the fix is easy, but I haven't been able to locate it yet. It probably has to do with the internal idea of the insertion point not getting updated properly. Note that the cursor on the screen is in the right spot, it's just that the first character gets inserted into the TypeIn or TypeScript in the wrong place (i.e., it is put at the place from the mouse move, not from the last arrow key move). Any assistance you can provide is very much appreciated and will go a long way toward keeping Modula-3 use alive and well for this project. If we can't fix this one, the customers will want to re-code everything in some Microsoft language, probably C++ or C#. I also have one other strange anomaly, but it is less of an issue at the moment. On a Dell M4300 laptop at 1920x1200 resolution, all pixmaps are getting stretched vertically. Text seems to be fine as do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out of proportion. This problem has not happened on all other platforms I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at 1400x1050, etc.). Any ideas on what could be the issue? I know that 1920x1200 is a strange resolution, but it is the native resolution for the M4300 laptop computer that the customer is using. I checked and the computer is set for 96dpi (normal). Perhaps there is some Trestle setting that I need to tweak on this platform, or perhaps there is a bug that needs fixing. Regards, Randy Coleburn Senior Systems Engineer Scientific Research Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 29 23:04:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Jul 2008 22:04:53 +0100 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <488F4292.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> Message-ID: <24C18663-4CA5-4DBA-AC2E-240FBBD6EF47@cs.purdue.edu> Hmm, do we have any Trestle gurus these days? On Jul 29, 2008, at 9:17 PM, Randy Coleburn wrote: > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a problem > that I have not been able to solve. I am hoping someone in the cm3 > community can help. I need to solve this problem ASAP this week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily reproduce > the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. > > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen is > in the right spot, it's just that the first character gets inserted > into the TypeIn or TypeScript in the wrong place (i.e., it is put at > the place from the mouse move, not from the last arrow key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to re- > code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is > using. I checked and the computer is set for 96dpi (normal). > Perhaps there is some Trestle setting that I need to tweak on this > platform, or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jul 30 05:46:28 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 30 Jul 2008 03:46:28 +0000 (GMT) Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <24C18663-4CA5-4DBA-AC2E-240FBBD6EF47@cs.purdue.edu> Message-ID: <714610.11568.qm@web27104.mail.ukl.yahoo.com> Dear all: I have some (user point of view) experience with trestle and as I see in a kubuntu 8.04 box here with almost up to date cm3 environment, I have not seen in formsedit the bug you report (at least in the source code box), and looking where is actually used TypeInVBT, it's not actually imported by any interface, see (on cm3ide): http://localhost:3800/public/ui/src/split/TypeInVBT.i3/ but it does TypeinVBT http://localhost:3800/public/vbtkit/src/etext/TypeinVBT.i3/ imported by several clients (including vbtkit). If I guess rigth you migth be using that TypeinVBT. As I say works fine (with this linux box in the formsedit program on the source code box). So I think if you have tested this software with a previous version of Trestle and it worked fine, then I think the? changes made in the cm3 sources have affected the mentioned Interface, so it's easier to catch the bug, but if you haven't tested with the previous version of Trestle (is not possible, or the behaviour is the same with both versions of Trestle), then could be some ?? win32 dependant interface causing the bug. Could you make that comparison with of both Trestle implemenations using formsedit? I can give it a try (first, setting a working win32 box with cm3) and see what happens with formsedit (or if you have a win32 box I can point an url of m3browser or cm3ide) to get an idea of what happens deeping in the sources of both implementations (from formsedit source). Let me know if this is useful. Good luck.? --- El mar, 29/7/08, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week Para: "Randy Coleburn" CC: m3devel at elegosoft.com, m3-support at elego.de Fecha: martes, 29 julio, 2008 4:04 Hmm, do we have any Trestle gurus these days? On Jul 29, 2008, at 9:17 PM, Randy Coleburn wrote: Hi: ? I've been using cm3 to develop software I am delivering this week to a customer.? During the acceptance testing, we've run into a problem that I have not been able to solve.? I am hoping someone in the cm3 community can help.? I need to solve this problem ASAP this week. ? This problem is easily reproduced using the "formsedit" program. ? The problem is with the?TypeIn and TypeScript FormsVBT elements used in my program.? Since formsedit uses these, you can easily reproduce the problem. ? Click with the mouse to move the insertion point somewhere in the text.? Observe that the cursor moves to that point.? Now, use the left arrow key to move the insertion point a few characters to the left.? Then, type a few characters.? Observe that the first character you type shows up at the place where you initially moved the cursor with the mouse, while the remaining characters show up at the place where you moved the cursor via the left-arrow key.? This behavior is wrong.? The first character you type should be at the current insertion point, not at the one from the mouse move. ? I'm sure the fix is easy, but I haven't been able to locate it yet.? It probably has to do with the internal idea of the insertion point not getting updated properly.? Note that the cursor on the screen is in the right spot, it's just that the first character gets inserted into the TypeIn or TypeScript in the wrong place (i.e., it is put at the place from the mouse move, not from the last arrow key move). ? Any assistance you can provide is very much appreciated and will go a long way toward keeping Modula-3 use alive and well for this project.? If we can't fix this one, the customers will want to re-code everything in some Microsoft language, probably C++ or C#. ? I also have one other strange anomaly, but it is less of an issue at the moment.? On a Dell M4300 laptop at 1920x1200 resolution, all pixmaps are getting stretched vertically.? Text seems to be fine as do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out of proportion.? This problem has not happened on all other platforms I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at 1400x1050, etc.).? Any ideas on what could be the issue?? I know that 1920x1200 is a strange resolution, but it is the native resolution for the M4300 laptop computer that the customer is using.? I checked and the computer is set for 96dpi (normal).? Perhaps there is some Trestle setting that I need to tweak on this platform, or perhaps there is a bug that needs fixing. ? Regards, Randy Coleburn Senior Systems Engineer Scientific Research Corporation ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 30 08:24:11 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 30 Jul 2008 08:24:11 +0200 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <488F4292.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> Message-ID: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Quoting Randy Coleburn : > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a > problem that I have not been able to solve. I am hoping someone in > the cm3 community can help. I need to solve this problem ASAP this > week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily > reproduce the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. Randy, I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able to reproduce the problem on FreeBSD 6.3. Does the problem show up on all platforms you are working on? Which are these? Are there any local modifications to the libraries which I may not have? If it occurs only on Unix, it may be possible that a weird window manager interferes with the event delivery; otherwise I've got no good idea. If on Unix, you/we could perhaps test the behaviour on a different (remote) X display? Please provide more data about the problem context and how to reproduce it. Regards, Olaf > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen > is in the right spot, it's just that the first character gets > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > is put at the place from the mouse move, not from the last arrow > key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to > re-code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is using. > I checked and the computer is set for 96dpi (normal). Perhaps > there is some Trestle setting that I need to tweak on this platform, > or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation > -- 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 rodney.bates at wichita.edu Wed Jul 30 19:12:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 30 Jul 2008 12:12:43 -0500 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Message-ID: <4890A10B.4050701@wichita.edu> I can't reproduce it in LINUXLIBC6 either. Olaf Wagner wrote: > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 31 04:31:01 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 30 Jul 2008 22:31:01 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Message-ID: <4890EB9C.1E75.00D7.1@scires.com> Hi Olaf, Daniel, Rodney, et al: Thanks for your responses so far. Sorry for the delay in replying, but our email server has been offline for nearly 24-hours. There were some severe electrical storms that took down both redundant power systems for our email system. Hope I have not missed any of your replies. Right now, I am delivering the software on Windows XP using SP2 or greater. I have not tried to see if this problem also occurs on Unix. I don't have ready access to a unix system from my current location. So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any event, it is a real problem for me. As for the pixmap stretching problem, I have tested various resolutions on the customer's computer. Unfortunately, the customer demands that the display resolution stay at the 1920x1200. 1920x1200=pixmap stretch problem 1680x1050=pixmap stretch problem 1440x900=no problem 1024x768=no problem Regards, Randy >>> Olaf Wagner 7/30/2008 2:24 AM >>> Quoting Randy Coleburn : > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a > problem that I have not been able to solve. I am hoping someone in > the cm3 community can help. I need to solve this problem ASAP this > week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily > reproduce the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. Randy, I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able to reproduce the problem on FreeBSD 6.3. Does the problem show up on all platforms you are working on? Which are these? Are there any local modifications to the libraries which I may not have? If it occurs only on Unix, it may be possible that a weird window manager interferes with the event delivery; otherwise I've got no good idea. If on Unix, you/we could perhaps test the behaviour on a different (remote) X display? Please provide more data about the problem context and how to reproduce it. Regards, Olaf > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen > is in the right spot, it's just that the first character gets > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > is put at the place from the mouse move, not from the last arrow > key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to > re-code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is using. > I checked and the computer is set for 96dpi (normal). Perhaps > there is some Trestle setting that I need to tweak on this platform, > or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Jul 31 15:33:12 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 31 Jul 2008 08:33:12 -0500 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4890EB9C.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> Message-ID: <4891BF18.8000905@wichita.edu> Which variant of the M3 Windows target are you using? I don't have any of them built right now. Randy Coleburn wrote: > Hi Olaf, Daniel, Rodney, et al: > > Thanks for your responses so far. Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours. There were some > severe electrical storms that took down both redundant power systems for > our email system. Hope I have not missed any of your replies. > > Right now, I am delivering the software on Windows XP using SP2 or > greater. I have not tried to see if this problem also occurs on Unix. > I don't have ready access to a unix system from my current location. > > So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any > event, it is a real problem for me. > > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer. Unfortunately, the customer demands that > the display resolution stay at the 1920x1200. > 1920x1200=pixmap stretch problem > 1680x1050=pixmap stretch problem > 1440x900=no problem > 1024x768=no problem > > Regards, > Randy > > >>> Olaf Wagner 7/30/2008 2:24 AM >>> > Quoting Randy Coleburn : > > > Hi: > > > > I've been using cm3 to develop software I am delivering this week to > > a customer. During the acceptance testing, we've run into a > > problem that I have not been able to solve. I am hoping someone in > > the cm3 community can help. I need to solve this problem ASAP this > > week. > > > > This problem is easily reproduced using the "formsedit" program. > > > > The problem is with the TypeIn and TypeScript FormsVBT elements used > > in my program. Since formsedit uses these, you can easily > > reproduce the problem. > > > > Click with the mouse to move the insertion point somewhere in the > > text. Observe that the cursor moves to that point. Now, use the > > left arrow key to move the insertion point a few characters to the > > left. Then, type a few characters. Observe that the first > > character you type shows up at the place where you initially moved > > the cursor with the mouse, while the remaining characters show up at > > the place where you moved the cursor via the left-arrow key. This > > behavior is wrong. The first character you type should be at the > > current insertion point, not at the one from the mouse move. > > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > > > I'm sure the fix is easy, but I haven't been able to locate it yet. > > It probably has to do with the internal idea of the insertion point > > not getting updated properly. Note that the cursor on the screen > > is in the right spot, it's just that the first character gets > > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > > is put at the place from the mouse move, not from the last arrow > > key move). > > > > Any assistance you can provide is very much appreciated and will go > > a long way toward keeping Modula-3 use alive and well for this > > project. If we can't fix this one, the customers will want to > > re-code everything in some Microsoft language, probably C++ or C#. > > > > I also have one other strange anomaly, but it is less of an issue at > > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > > pixmaps are getting stretched vertically. Text seems to be fine as > > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > > of proportion. This problem has not happened on all other platforms > > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > > 1400x1050, etc.). Any ideas on what could be the issue? I know > > that 1920x1200 is a strange resolution, but it is the native > > resolution for the M4300 laptop computer that the customer is using. > > I checked and the computer is set for 96dpi (normal). Perhaps > > there is some Trestle setting that I need to tweak on this platform, > > or perhaps there is a bug that needs fixing. > > > > Regards, > > Randy Coleburn > > Senior Systems Engineer > > Scientific Research Corporation > > > > > > -- > 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 > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 31 17:51:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jul 2008 11:51:28 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4891BF18.8000905@wichita.edu> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> Message-ID: <4891A737.1E75.00D7.1@scires.com> Rodney: I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied). Michel Dagenais suggested that if the problem does not reproduce on Linux, that it might have to do with how Windows reports character events. He thought a Filter VBT may exist somewhere that would aid in debugging by printing method calls before propagating them to father/son. This filter VBT would be inserted at different places in the VBT tree to get tracing information. Are you familiar with something like this? As for the pixmaps, Michel suggests increasing the resolution of the original pixmap to help alleviate problems with upscaling. I may try this, but of course, FormsVBT uses a lot of pixmap resources, for example, radio, boolean, checkmark, numeric, etc all use pixmaps. Regards, Randy >>> "Rodney M. Bates" 7/31/2008 9:33 AM >>> Which variant of the M3 Windows target are you using? I don't have any of them built right now. Randy Coleburn wrote: > Hi Olaf, Daniel, Rodney, et al: > > Thanks for your responses so far. Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours. There were some > severe electrical storms that took down both redundant power systems for > our email system. Hope I have not missed any of your replies. > > Right now, I am delivering the software on Windows XP using SP2 or > greater. I have not tried to see if this problem also occurs on Unix. > I don't have ready access to a unix system from my current location. > > So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any > event, it is a real problem for me. > > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer. Unfortunately, the customer demands that > the display resolution stay at the 1920x1200. > 1920x1200=pixmap stretch problem > 1680x1050=pixmap stretch problem > 1440x900=no problem > 1024x768=no problem > > Regards, > Randy > > >>> Olaf Wagner 7/30/2008 2:24 AM >>> > Quoting Randy Coleburn : > > > Hi: > > > > I've been using cm3 to develop software I am delivering this week to > > a customer. During the acceptance testing, we've run into a > > problem that I have not been able to solve. I am hoping someone in > > the cm3 community can help. I need to solve this problem ASAP this > > week. > > > > This problem is easily reproduced using the "formsedit" program. > > > > The problem is with the TypeIn and TypeScript FormsVBT elements used > > in my program. Since formsedit uses these, you can easily > > reproduce the problem. > > > > Click with the mouse to move the insertion point somewhere in the > > text. Observe that the cursor moves to that point. Now, use the > > left arrow key to move the insertion point a few characters to the > > left. Then, type a few characters. Observe that the first > > character you type shows up at the place where you initially moved > > the cursor with the mouse, while the remaining characters show up at > > the place where you moved the cursor via the left-arrow key. This > > behavior is wrong. The first character you type should be at the > > current insertion point, not at the one from the mouse move. > > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > > > I'm sure the fix is easy, but I haven't been able to locate it yet. > > It probably has to do with the internal idea of the insertion point > > not getting updated properly. Note that the cursor on the screen > > is in the right spot, it's just that the first character gets > > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > > is put at the place from the mouse move, not from the last arrow > > key move). > > > > Any assistance you can provide is very much appreciated and will go > > a long way toward keeping Modula-3 use alive and well for this > > project. If we can't fix this one, the customers will want to > > re-code everything in some Microsoft language, probably C++ or C#. > > > > I also have one other strange anomaly, but it is less of an issue at > > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > > pixmaps are getting stretched vertically. Text seems to be fine as > > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > > of proportion. This problem has not happened on all other platforms > > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > > 1400x1050, etc.). Any ideas on what could be the issue? I know > > that 1920x1200 is a strange resolution, but it is the native > > resolution for the M4300 laptop computer that the customer is using. > > I checked and the computer is set for 96dpi (normal). Perhaps > > there is some Trestle setting that I need to tweak on this platform, > > or perhaps there is a bug that needs fixing. > > > > Regards, > > Randy Coleburn > > Senior Systems Engineer > > Scientific Research Corporation > > > > > > -- > 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 > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 31 18:44:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jul 2008 18:44:49 +0200 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4891A737.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> <4891A737.1E75.00D7.1@scires.com> Message-ID: <20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com> Quoting Randy Coleburn : > Rodney: > > I am using Windows XP Professional, Service Pack 2 (on some systems, > Service Pack 3 is applied). Hi Randy, I just tried formsedit on exactly this system (XP professional, SP2) in my virtual machine, and wasn't able to see any fault wrt. cursor processing and typing, too. I checked-out and compiled all the latest sources of the relevant gui packages (ui, vbtkit, formsvbt etc.), but that didn't make any difference (though some changes had been applied). For me it just seems to work correctly. It may be of interest though that some months ago when I was last working on this system for the regression tests, I applied all existing Microsoft patches; but you've done that probably, too. I've got no idea about the pixmap problem, too. As long as nobody else is able to reproduce the problem it will remain difficult to analyze this problem. Sorry that I cannot be of more help, Olaf PS: Are you sure that you are really using exactly the current CM3 gui libraries, and not some adapted or modified stuff from an older release? > Michel Dagenais suggested that if the problem does not reproduce on > Linux, that it might have to do with how Windows reports character > events. He thought a Filter VBT may exist somewhere that would aid in > debugging by printing method calls before propagating them to > father/son. This filter VBT would be inserted at different places in > the VBT tree to get tracing information. Are you familiar with > something like this? > > As for the pixmaps, Michel suggests increasing the resolution of the > original pixmap to help alleviate problems with upscaling. I may try > this, but of course, FormsVBT uses a lot of pixmap resources, for > example, radio, boolean, checkmark, numeric, etc all use pixmaps. > > Regards, > Randy > >>>> "Rodney M. Bates" 7/31/2008 9:33 AM >>> > Which variant of the M3 Windows target are you using? I don't have > any > of them built right now. > > Randy Coleburn wrote: >> Hi Olaf, Daniel, Rodney, et al: >> >> Thanks for your responses so far. Sorry for the delay in replying, > but >> our email server has been offline for nearly 24-hours. There were > some >> severe electrical storms that took down both redundant power systems > for >> our email system. Hope I have not missed any of your replies. >> >> Right now, I am delivering the software on Windows XP using SP2 or >> greater. I have not tried to see if this problem also occurs on > Unix. >> I don't have ready access to a unix system from my current location. >> >> So it is perhaps a Windows-only problem with Trestle/FormsVBT. In > any >> event, it is a real problem for me. >> >> As for the pixmap stretching problem, I have tested various > resolutions >> on the customer's computer. Unfortunately, the customer demands that > >> the display resolution stay at the 1920x1200. >> 1920x1200=pixmap stretch problem >> 1680x1050=pixmap stretch problem >> 1440x900=no problem >> 1024x768=no problem >> >> Regards, >> Randy >> >> >>> Olaf Wagner 7/30/2008 2:24 AM >>> >> Quoting Randy Coleburn : >> >> > Hi: >> > >> > I've been using cm3 to develop software I am delivering this week > to >> > a customer. During the acceptance testing, we've run into a >> > problem that I have not been able to solve. I am hoping someone > in >> > the cm3 community can help. I need to solve this problem ASAP > this >> > week. >> > >> > This problem is easily reproduced using the "formsedit" program. >> > >> > The problem is with the TypeIn and TypeScript FormsVBT elements > used >> > in my program. Since formsedit uses these, you can easily >> > reproduce the problem. >> > >> > Click with the mouse to move the insertion point somewhere in the > >> > text. Observe that the cursor moves to that point. Now, use the > >> > left arrow key to move the insertion point a few characters to the > >> > left. Then, type a few characters. Observe that the first >> > character you type shows up at the place where you initially moved > >> > the cursor with the mouse, while the remaining characters show up > at >> > the place where you moved the cursor via the left-arrow key. > This >> > behavior is wrong. The first character you type should be at the > >> > current insertion point, not at the one from the mouse move. >> >> Randy, >> >> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't > able >> to reproduce the problem on FreeBSD 6.3. >> >> Does the problem show up on all platforms you are working on? >> Which are these? >> >> Are there any local modifications to the libraries which I may not >> have? >> >> If it occurs only on Unix, it may be possible that a weird window >> manager interferes with the event delivery; otherwise I've got no >> good idea. If on Unix, you/we could perhaps test the behaviour >> on a different (remote) X display? >> >> Please provide more data about the problem context and how to >> reproduce it. >> >> Regards, >> >> Olaf >> >> > I'm sure the fix is easy, but I haven't been able to locate it > yet. >> > It probably has to do with the internal idea of the insertion > point >> > not getting updated properly. Note that the cursor on the screen > >> > is in the right spot, it's just that the first character gets >> > inserted into the TypeIn or TypeScript in the wrong place (i.e., > it >> > is put at the place from the mouse move, not from the last arrow > >> > key move). >> > >> > Any assistance you can provide is very much appreciated and will > go >> > a long way toward keeping Modula-3 use alive and well for this >> > project. If we can't fix this one, the customers will want to >> > re-code everything in some Microsoft language, probably C++ or > C#. >> > >> > I also have one other strange anomaly, but it is less of an issue > at >> > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > >> > pixmaps are getting stretched vertically. Text seems to be fine > as >> > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched > out >> > of proportion. This problem has not happened on all other > platforms >> > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 > at >> > 1400x1050, etc.). Any ideas on what could be the issue? I know > >> > that 1920x1200 is a strange resolution, but it is the native >> > resolution for the M4300 laptop computer that the customer is > using. >> > I checked and the computer is set for 96dpi (normal). Perhaps > >> > there is some Trestle setting that I need to tweak on this > platform, >> > or perhaps there is a bug that needs fixing. >> > >> > Regards, >> > Randy Coleburn >> > Senior Systems Engineer >> > Scientific Research Corporation >> > >> >> >> >> -- >> 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 >> >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu > > -- 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 rodney.bates at wichita.edu Thu Jul 3 01:33:21 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 02 Jul 2008 18:33:21 -0500 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 Message-ID: <486C1041.4060004@wichita.edu> Using a freshly installed cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails with: === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ --- building in LINUXLIBC6 --- Fatal Error: bad version stamps: RTArgs.m3 RTArgs.m3: missing imported type: _tf3a6cedc RTArgs.m3: missing imported type: _t8b2831d7 *** execution of cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' failed *** Sounds like another bootstrapping problem of some kind. Shouldn't the latest snapshot work on current cvs? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Thu Jul 3 10:16:41 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Jul 2008 10:16:41 +0200 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 In-Reply-To: <486C1041.4060004@wichita.edu> References: <486C1041.4060004@wichita.edu> Message-ID: <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Using a freshly installed > cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, > and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails with: > > === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === > +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V > ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in LINUXLIBC6 --- > > Fatal Error: bad version stamps: RTArgs.m3 > > RTArgs.m3: missing imported type: _tf3a6cedc > RTArgs.m3: missing imported type: _t8b2831d7 > *** execution of cm3 -build -override > -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 > .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' > failed *** > > Sounds like another bootstrapping problem of some kind. Shouldn't the latest > snapshot work on current cvs? As the snapshot archives are built every night from a current CVS checkout, this should surely be the case. I bet you've got some old derived files in your workspace and didn't clear them properly. Try ./scripts/do-cm3-all.sh realclean. 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 rodney.bates at wichita.edu Fri Jul 4 18:45:53 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 04 Jul 2008 11:45:53 -0500 Subject: [M3devel] latest snapshot won't compile latest cvs RTArgs.m3 In-Reply-To: <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> References: <486C1041.4060004@wichita.edu> <20080703101641.7ycnjbgqckwg0osg@mail.elegosoft.com> Message-ID: <486E53C1.7020907@wichita.edu> Ah, realclean. I tend to forget about that when I think I'm just doing a fresh build. Thanks, that fixed that problem. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> Using a freshly installed >> cm3-min-POSIX-LINUXLIBC6-d5.7.0-2008-07-02-14-00-05.tgz, >> and a freshly updated cvs cm3 repository, do-cm3-core.sh build fails >> with: >> >> === package /home/rodney/proj/m3/cm3-new/cm3/m3-libs/parseparams === >> +++ cm3 -build -override -DROOT='/home/rodney/proj/m3/cm3-new/cm3' >> -DCM3_VERSION_TEXT='d5.7.0' -DCM3_V >> ERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ >> --- building in LINUXLIBC6 --- >> >> Fatal Error: bad version stamps: RTArgs.m3 >> >> RTArgs.m3: missing imported type: _tf3a6cedc >> RTArgs.m3: missing imported type: _t8b2831d7 >> *** execution of cm3 -build -override >> -DROOT='/home/rodney/proj/m3/cm3-new/cm3' -DCM3_VERSION_TEXT='d5 >> .7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' >> failed *** >> >> Sounds like another bootstrapping problem of some kind. Shouldn't the >> latest >> snapshot work on current cvs? > > > As the snapshot archives are built every night from a current CVS > checkout, this should surely be the case. I bet you've got some > old derived files in your workspace and didn't clear them > properly. Try ./scripts/do-cm3-all.sh realclean. > > Olaf -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Fri Jul 18 19:21:57 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 18 Jul 2008 17:21:57 +0000 (GMT) Subject: [M3devel] Luca Cardelli Interview and video tape resources Message-ID: <484587.75213.qm@web27102.mail.ukl.yahoo.com> Dear all, check the link http://www.computerworld.com.au/index.php/id;1422447371;fp;;fpid; Besides, does anyone know if the video tapes of the research reports (including the one of the language release) is available for download or external lend of a library? I found this one from http://wally.rit.edu/pubs/guides/csvideo.html? : OPERATING SYSTEMS & LANGUAGES MRC VH 701K Donahue, Jim. Modula-3 . UVC, 1991. Lecture by Jim Donahue, Olivetti Research California. Summarizes the joint work of ORC and DEC's Systems Research Center to design Modula-3, a new systems programming language descending from Mesa, Modula-2, and Modula 2+. Describes the principles that drove the language design and discusses the most important features of the language, emphasizing the type system, its most innovative feature. Ends with a Q&A session. the above can be checked on: http://albert.rit.edu/record=b1251585 also in (Hong Kong): http://lib.cityu.edu.hk/record=b1165121 ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jul 29 22:17:35 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 29 Jul 2008 16:17:35 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week Message-ID: <488F4292.1E75.00D7.1@scires.com> Hi: I've been using cm3 to develop software I am delivering this week to a customer. During the acceptance testing, we've run into a problem that I have not been able to solve. I am hoping someone in the cm3 community can help. I need to solve this problem ASAP this week. This problem is easily reproduced using the "formsedit" program. The problem is with the TypeIn and TypeScript FormsVBT elements used in my program. Since formsedit uses these, you can easily reproduce the problem. Click with the mouse to move the insertion point somewhere in the text. Observe that the cursor moves to that point. Now, use the left arrow key to move the insertion point a few characters to the left. Then, type a few characters. Observe that the first character you type shows up at the place where you initially moved the cursor with the mouse, while the remaining characters show up at the place where you moved the cursor via the left-arrow key. This behavior is wrong. The first character you type should be at the current insertion point, not at the one from the mouse move. I'm sure the fix is easy, but I haven't been able to locate it yet. It probably has to do with the internal idea of the insertion point not getting updated properly. Note that the cursor on the screen is in the right spot, it's just that the first character gets inserted into the TypeIn or TypeScript in the wrong place (i.e., it is put at the place from the mouse move, not from the last arrow key move). Any assistance you can provide is very much appreciated and will go a long way toward keeping Modula-3 use alive and well for this project. If we can't fix this one, the customers will want to re-code everything in some Microsoft language, probably C++ or C#. I also have one other strange anomaly, but it is less of an issue at the moment. On a Dell M4300 laptop at 1920x1200 resolution, all pixmaps are getting stretched vertically. Text seems to be fine as do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out of proportion. This problem has not happened on all other platforms I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at 1400x1050, etc.). Any ideas on what could be the issue? I know that 1920x1200 is a strange resolution, but it is the native resolution for the M4300 laptop computer that the customer is using. I checked and the computer is set for 96dpi (normal). Perhaps there is some Trestle setting that I need to tweak on this platform, or perhaps there is a bug that needs fixing. Regards, Randy Coleburn Senior Systems Engineer Scientific Research Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 29 23:04:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Jul 2008 22:04:53 +0100 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <488F4292.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> Message-ID: <24C18663-4CA5-4DBA-AC2E-240FBBD6EF47@cs.purdue.edu> Hmm, do we have any Trestle gurus these days? On Jul 29, 2008, at 9:17 PM, Randy Coleburn wrote: > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a problem > that I have not been able to solve. I am hoping someone in the cm3 > community can help. I need to solve this problem ASAP this week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily reproduce > the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. > > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen is > in the right spot, it's just that the first character gets inserted > into the TypeIn or TypeScript in the wrong place (i.e., it is put at > the place from the mouse move, not from the last arrow key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to re- > code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is > using. I checked and the computer is set for 96dpi (normal). > Perhaps there is some Trestle setting that I need to tweak on this > platform, or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jul 30 05:46:28 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 30 Jul 2008 03:46:28 +0000 (GMT) Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <24C18663-4CA5-4DBA-AC2E-240FBBD6EF47@cs.purdue.edu> Message-ID: <714610.11568.qm@web27104.mail.ukl.yahoo.com> Dear all: I have some (user point of view) experience with trestle and as I see in a kubuntu 8.04 box here with almost up to date cm3 environment, I have not seen in formsedit the bug you report (at least in the source code box), and looking where is actually used TypeInVBT, it's not actually imported by any interface, see (on cm3ide): http://localhost:3800/public/ui/src/split/TypeInVBT.i3/ but it does TypeinVBT http://localhost:3800/public/vbtkit/src/etext/TypeinVBT.i3/ imported by several clients (including vbtkit). If I guess rigth you migth be using that TypeinVBT. As I say works fine (with this linux box in the formsedit program on the source code box). So I think if you have tested this software with a previous version of Trestle and it worked fine, then I think the? changes made in the cm3 sources have affected the mentioned Interface, so it's easier to catch the bug, but if you haven't tested with the previous version of Trestle (is not possible, or the behaviour is the same with both versions of Trestle), then could be some ?? win32 dependant interface causing the bug. Could you make that comparison with of both Trestle implemenations using formsedit? I can give it a try (first, setting a working win32 box with cm3) and see what happens with formsedit (or if you have a win32 box I can point an url of m3browser or cm3ide) to get an idea of what happens deeping in the sources of both implementations (from formsedit source). Let me know if this is useful. Good luck.? --- El mar, 29/7/08, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week Para: "Randy Coleburn" CC: m3devel at elegosoft.com, m3-support at elego.de Fecha: martes, 29 julio, 2008 4:04 Hmm, do we have any Trestle gurus these days? On Jul 29, 2008, at 9:17 PM, Randy Coleburn wrote: Hi: ? I've been using cm3 to develop software I am delivering this week to a customer.? During the acceptance testing, we've run into a problem that I have not been able to solve.? I am hoping someone in the cm3 community can help.? I need to solve this problem ASAP this week. ? This problem is easily reproduced using the "formsedit" program. ? The problem is with the?TypeIn and TypeScript FormsVBT elements used in my program.? Since formsedit uses these, you can easily reproduce the problem. ? Click with the mouse to move the insertion point somewhere in the text.? Observe that the cursor moves to that point.? Now, use the left arrow key to move the insertion point a few characters to the left.? Then, type a few characters.? Observe that the first character you type shows up at the place where you initially moved the cursor with the mouse, while the remaining characters show up at the place where you moved the cursor via the left-arrow key.? This behavior is wrong.? The first character you type should be at the current insertion point, not at the one from the mouse move. ? I'm sure the fix is easy, but I haven't been able to locate it yet.? It probably has to do with the internal idea of the insertion point not getting updated properly.? Note that the cursor on the screen is in the right spot, it's just that the first character gets inserted into the TypeIn or TypeScript in the wrong place (i.e., it is put at the place from the mouse move, not from the last arrow key move). ? Any assistance you can provide is very much appreciated and will go a long way toward keeping Modula-3 use alive and well for this project.? If we can't fix this one, the customers will want to re-code everything in some Microsoft language, probably C++ or C#. ? I also have one other strange anomaly, but it is less of an issue at the moment.? On a Dell M4300 laptop at 1920x1200 resolution, all pixmaps are getting stretched vertically.? Text seems to be fine as do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out of proportion.? This problem has not happened on all other platforms I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at 1400x1050, etc.).? Any ideas on what could be the issue?? I know that 1920x1200 is a strange resolution, but it is the native resolution for the M4300 laptop computer that the customer is using.? I checked and the computer is set for 96dpi (normal).? Perhaps there is some Trestle setting that I need to tweak on this platform, or perhaps there is a bug that needs fixing. ? Regards, Randy Coleburn Senior Systems Engineer Scientific Research Corporation ______________________________________________ Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jul 30 08:24:11 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 30 Jul 2008 08:24:11 +0200 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <488F4292.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> Message-ID: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Quoting Randy Coleburn : > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a > problem that I have not been able to solve. I am hoping someone in > the cm3 community can help. I need to solve this problem ASAP this > week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily > reproduce the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. Randy, I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able to reproduce the problem on FreeBSD 6.3. Does the problem show up on all platforms you are working on? Which are these? Are there any local modifications to the libraries which I may not have? If it occurs only on Unix, it may be possible that a weird window manager interferes with the event delivery; otherwise I've got no good idea. If on Unix, you/we could perhaps test the behaviour on a different (remote) X display? Please provide more data about the problem context and how to reproduce it. Regards, Olaf > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen > is in the right spot, it's just that the first character gets > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > is put at the place from the mouse move, not from the last arrow > key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to > re-code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is using. > I checked and the computer is set for 96dpi (normal). Perhaps > there is some Trestle setting that I need to tweak on this platform, > or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation > -- 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 rodney.bates at wichita.edu Wed Jul 30 19:12:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 30 Jul 2008 12:12:43 -0500 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Message-ID: <4890A10B.4050701@wichita.edu> I can't reproduce it in LINUXLIBC6 either. Olaf Wagner wrote: > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 31 04:31:01 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 30 Jul 2008 22:31:01 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> Message-ID: <4890EB9C.1E75.00D7.1@scires.com> Hi Olaf, Daniel, Rodney, et al: Thanks for your responses so far. Sorry for the delay in replying, but our email server has been offline for nearly 24-hours. There were some severe electrical storms that took down both redundant power systems for our email system. Hope I have not missed any of your replies. Right now, I am delivering the software on Windows XP using SP2 or greater. I have not tried to see if this problem also occurs on Unix. I don't have ready access to a unix system from my current location. So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any event, it is a real problem for me. As for the pixmap stretching problem, I have tested various resolutions on the customer's computer. Unfortunately, the customer demands that the display resolution stay at the 1920x1200. 1920x1200=pixmap stretch problem 1680x1050=pixmap stretch problem 1440x900=no problem 1024x768=no problem Regards, Randy >>> Olaf Wagner 7/30/2008 2:24 AM >>> Quoting Randy Coleburn : > Hi: > > I've been using cm3 to develop software I am delivering this week to > a customer. During the acceptance testing, we've run into a > problem that I have not been able to solve. I am hoping someone in > the cm3 community can help. I need to solve this problem ASAP this > week. > > This problem is easily reproduced using the "formsedit" program. > > The problem is with the TypeIn and TypeScript FormsVBT elements used > in my program. Since formsedit uses these, you can easily > reproduce the problem. > > Click with the mouse to move the insertion point somewhere in the > text. Observe that the cursor moves to that point. Now, use the > left arrow key to move the insertion point a few characters to the > left. Then, type a few characters. Observe that the first > character you type shows up at the place where you initially moved > the cursor with the mouse, while the remaining characters show up at > the place where you moved the cursor via the left-arrow key. This > behavior is wrong. The first character you type should be at the > current insertion point, not at the one from the mouse move. Randy, I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able to reproduce the problem on FreeBSD 6.3. Does the problem show up on all platforms you are working on? Which are these? Are there any local modifications to the libraries which I may not have? If it occurs only on Unix, it may be possible that a weird window manager interferes with the event delivery; otherwise I've got no good idea. If on Unix, you/we could perhaps test the behaviour on a different (remote) X display? Please provide more data about the problem context and how to reproduce it. Regards, Olaf > I'm sure the fix is easy, but I haven't been able to locate it yet. > It probably has to do with the internal idea of the insertion point > not getting updated properly. Note that the cursor on the screen > is in the right spot, it's just that the first character gets > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > is put at the place from the mouse move, not from the last arrow > key move). > > Any assistance you can provide is very much appreciated and will go > a long way toward keeping Modula-3 use alive and well for this > project. If we can't fix this one, the customers will want to > re-code everything in some Microsoft language, probably C++ or C#. > > I also have one other strange anomaly, but it is less of an issue at > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > pixmaps are getting stretched vertically. Text seems to be fine as > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > of proportion. This problem has not happened on all other platforms > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > 1400x1050, etc.). Any ideas on what could be the issue? I know > that 1920x1200 is a strange resolution, but it is the native > resolution for the M4300 laptop computer that the customer is using. > I checked and the computer is set for 96dpi (normal). Perhaps > there is some Trestle setting that I need to tweak on this platform, > or perhaps there is a bug that needs fixing. > > Regards, > Randy Coleburn > Senior Systems Engineer > Scientific Research Corporation > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Jul 31 15:33:12 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 31 Jul 2008 08:33:12 -0500 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4890EB9C.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> Message-ID: <4891BF18.8000905@wichita.edu> Which variant of the M3 Windows target are you using? I don't have any of them built right now. Randy Coleburn wrote: > Hi Olaf, Daniel, Rodney, et al: > > Thanks for your responses so far. Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours. There were some > severe electrical storms that took down both redundant power systems for > our email system. Hope I have not missed any of your replies. > > Right now, I am delivering the software on Windows XP using SP2 or > greater. I have not tried to see if this problem also occurs on Unix. > I don't have ready access to a unix system from my current location. > > So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any > event, it is a real problem for me. > > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer. Unfortunately, the customer demands that > the display resolution stay at the 1920x1200. > 1920x1200=pixmap stretch problem > 1680x1050=pixmap stretch problem > 1440x900=no problem > 1024x768=no problem > > Regards, > Randy > > >>> Olaf Wagner 7/30/2008 2:24 AM >>> > Quoting Randy Coleburn : > > > Hi: > > > > I've been using cm3 to develop software I am delivering this week to > > a customer. During the acceptance testing, we've run into a > > problem that I have not been able to solve. I am hoping someone in > > the cm3 community can help. I need to solve this problem ASAP this > > week. > > > > This problem is easily reproduced using the "formsedit" program. > > > > The problem is with the TypeIn and TypeScript FormsVBT elements used > > in my program. Since formsedit uses these, you can easily > > reproduce the problem. > > > > Click with the mouse to move the insertion point somewhere in the > > text. Observe that the cursor moves to that point. Now, use the > > left arrow key to move the insertion point a few characters to the > > left. Then, type a few characters. Observe that the first > > character you type shows up at the place where you initially moved > > the cursor with the mouse, while the remaining characters show up at > > the place where you moved the cursor via the left-arrow key. This > > behavior is wrong. The first character you type should be at the > > current insertion point, not at the one from the mouse move. > > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > > > I'm sure the fix is easy, but I haven't been able to locate it yet. > > It probably has to do with the internal idea of the insertion point > > not getting updated properly. Note that the cursor on the screen > > is in the right spot, it's just that the first character gets > > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > > is put at the place from the mouse move, not from the last arrow > > key move). > > > > Any assistance you can provide is very much appreciated and will go > > a long way toward keeping Modula-3 use alive and well for this > > project. If we can't fix this one, the customers will want to > > re-code everything in some Microsoft language, probably C++ or C#. > > > > I also have one other strange anomaly, but it is less of an issue at > > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > > pixmaps are getting stretched vertically. Text seems to be fine as > > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > > of proportion. This problem has not happened on all other platforms > > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > > 1400x1050, etc.). Any ideas on what could be the issue? I know > > that 1920x1200 is a strange resolution, but it is the native > > resolution for the M4300 laptop computer that the customer is using. > > I checked and the computer is set for 96dpi (normal). Perhaps > > there is some Trestle setting that I need to tweak on this platform, > > or perhaps there is a bug that needs fixing. > > > > Regards, > > Randy Coleburn > > Senior Systems Engineer > > Scientific Research Corporation > > > > > > -- > 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 > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 31 17:51:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jul 2008 11:51:28 -0400 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4891BF18.8000905@wichita.edu> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> Message-ID: <4891A737.1E75.00D7.1@scires.com> Rodney: I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied). Michel Dagenais suggested that if the problem does not reproduce on Linux, that it might have to do with how Windows reports character events. He thought a Filter VBT may exist somewhere that would aid in debugging by printing method calls before propagating them to father/son. This filter VBT would be inserted at different places in the VBT tree to get tracing information. Are you familiar with something like this? As for the pixmaps, Michel suggests increasing the resolution of the original pixmap to help alleviate problems with upscaling. I may try this, but of course, FormsVBT uses a lot of pixmap resources, for example, radio, boolean, checkmark, numeric, etc all use pixmaps. Regards, Randy >>> "Rodney M. Bates" 7/31/2008 9:33 AM >>> Which variant of the M3 Windows target are you using? I don't have any of them built right now. Randy Coleburn wrote: > Hi Olaf, Daniel, Rodney, et al: > > Thanks for your responses so far. Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours. There were some > severe electrical storms that took down both redundant power systems for > our email system. Hope I have not missed any of your replies. > > Right now, I am delivering the software on Windows XP using SP2 or > greater. I have not tried to see if this problem also occurs on Unix. > I don't have ready access to a unix system from my current location. > > So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any > event, it is a real problem for me. > > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer. Unfortunately, the customer demands that > the display resolution stay at the 1920x1200. > 1920x1200=pixmap stretch problem > 1680x1050=pixmap stretch problem > 1440x900=no problem > 1024x768=no problem > > Regards, > Randy > > >>> Olaf Wagner 7/30/2008 2:24 AM >>> > Quoting Randy Coleburn : > > > Hi: > > > > I've been using cm3 to develop software I am delivering this week to > > a customer. During the acceptance testing, we've run into a > > problem that I have not been able to solve. I am hoping someone in > > the cm3 community can help. I need to solve this problem ASAP this > > week. > > > > This problem is easily reproduced using the "formsedit" program. > > > > The problem is with the TypeIn and TypeScript FormsVBT elements used > > in my program. Since formsedit uses these, you can easily > > reproduce the problem. > > > > Click with the mouse to move the insertion point somewhere in the > > text. Observe that the cursor moves to that point. Now, use the > > left arrow key to move the insertion point a few characters to the > > left. Then, type a few characters. Observe that the first > > character you type shows up at the place where you initially moved > > the cursor with the mouse, while the remaining characters show up at > > the place where you moved the cursor via the left-arrow key. This > > behavior is wrong. The first character you type should be at the > > current insertion point, not at the one from the mouse move. > > Randy, > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able > to reproduce the problem on FreeBSD 6.3. > > Does the problem show up on all platforms you are working on? > Which are these? > > Are there any local modifications to the libraries which I may not > have? > > If it occurs only on Unix, it may be possible that a weird window > manager interferes with the event delivery; otherwise I've got no > good idea. If on Unix, you/we could perhaps test the behaviour > on a different (remote) X display? > > Please provide more data about the problem context and how to > reproduce it. > > Regards, > > Olaf > > > I'm sure the fix is easy, but I haven't been able to locate it yet. > > It probably has to do with the internal idea of the insertion point > > not getting updated properly. Note that the cursor on the screen > > is in the right spot, it's just that the first character gets > > inserted into the TypeIn or TypeScript in the wrong place (i.e., it > > is put at the place from the mouse move, not from the last arrow > > key move). > > > > Any assistance you can provide is very much appreciated and will go > > a long way toward keeping Modula-3 use alive and well for this > > project. If we can't fix this one, the customers will want to > > re-code everything in some Microsoft language, probably C++ or C#. > > > > I also have one other strange anomaly, but it is less of an issue at > > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > > pixmaps are getting stretched vertically. Text seems to be fine as > > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out > > of proportion. This problem has not happened on all other platforms > > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at > > 1400x1050, etc.). Any ideas on what could be the issue? I know > > that 1920x1200 is a strange resolution, but it is the native > > resolution for the M4300 laptop computer that the customer is using. > > I checked and the computer is set for 96dpi (normal). Perhaps > > there is some Trestle setting that I need to tweak on this platform, > > or perhaps there is a bug that needs fixing. > > > > Regards, > > Randy Coleburn > > Senior Systems Engineer > > Scientific Research Corporation > > > > > > -- > 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 > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jul 31 18:44:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jul 2008 18:44:49 +0200 Subject: [M3devel] need help with cm3 problem before I deliver software this week In-Reply-To: <4891A737.1E75.00D7.1@scires.com> References: <488F4292.1E75.00D7.1@scires.com> <20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com> <4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> <4891A737.1E75.00D7.1@scires.com> Message-ID: <20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com> Quoting Randy Coleburn : > Rodney: > > I am using Windows XP Professional, Service Pack 2 (on some systems, > Service Pack 3 is applied). Hi Randy, I just tried formsedit on exactly this system (XP professional, SP2) in my virtual machine, and wasn't able to see any fault wrt. cursor processing and typing, too. I checked-out and compiled all the latest sources of the relevant gui packages (ui, vbtkit, formsvbt etc.), but that didn't make any difference (though some changes had been applied). For me it just seems to work correctly. It may be of interest though that some months ago when I was last working on this system for the regression tests, I applied all existing Microsoft patches; but you've done that probably, too. I've got no idea about the pixmap problem, too. As long as nobody else is able to reproduce the problem it will remain difficult to analyze this problem. Sorry that I cannot be of more help, Olaf PS: Are you sure that you are really using exactly the current CM3 gui libraries, and not some adapted or modified stuff from an older release? > Michel Dagenais suggested that if the problem does not reproduce on > Linux, that it might have to do with how Windows reports character > events. He thought a Filter VBT may exist somewhere that would aid in > debugging by printing method calls before propagating them to > father/son. This filter VBT would be inserted at different places in > the VBT tree to get tracing information. Are you familiar with > something like this? > > As for the pixmaps, Michel suggests increasing the resolution of the > original pixmap to help alleviate problems with upscaling. I may try > this, but of course, FormsVBT uses a lot of pixmap resources, for > example, radio, boolean, checkmark, numeric, etc all use pixmaps. > > Regards, > Randy > >>>> "Rodney M. Bates" 7/31/2008 9:33 AM >>> > Which variant of the M3 Windows target are you using? I don't have > any > of them built right now. > > Randy Coleburn wrote: >> Hi Olaf, Daniel, Rodney, et al: >> >> Thanks for your responses so far. Sorry for the delay in replying, > but >> our email server has been offline for nearly 24-hours. There were > some >> severe electrical storms that took down both redundant power systems > for >> our email system. Hope I have not missed any of your replies. >> >> Right now, I am delivering the software on Windows XP using SP2 or >> greater. I have not tried to see if this problem also occurs on > Unix. >> I don't have ready access to a unix system from my current location. >> >> So it is perhaps a Windows-only problem with Trestle/FormsVBT. In > any >> event, it is a real problem for me. >> >> As for the pixmap stretching problem, I have tested various > resolutions >> on the customer's computer. Unfortunately, the customer demands that > >> the display resolution stay at the 1920x1200. >> 1920x1200=pixmap stretch problem >> 1680x1050=pixmap stretch problem >> 1440x900=no problem >> 1024x768=no problem >> >> Regards, >> Randy >> >> >>> Olaf Wagner 7/30/2008 2:24 AM >>> >> Quoting Randy Coleburn : >> >> > Hi: >> > >> > I've been using cm3 to develop software I am delivering this week > to >> > a customer. During the acceptance testing, we've run into a >> > problem that I have not been able to solve. I am hoping someone > in >> > the cm3 community can help. I need to solve this problem ASAP > this >> > week. >> > >> > This problem is easily reproduced using the "formsedit" program. >> > >> > The problem is with the TypeIn and TypeScript FormsVBT elements > used >> > in my program. Since formsedit uses these, you can easily >> > reproduce the problem. >> > >> > Click with the mouse to move the insertion point somewhere in the > >> > text. Observe that the cursor moves to that point. Now, use the > >> > left arrow key to move the insertion point a few characters to the > >> > left. Then, type a few characters. Observe that the first >> > character you type shows up at the place where you initially moved > >> > the cursor with the mouse, while the remaining characters show up > at >> > the place where you moved the cursor via the left-arrow key. > This >> > behavior is wrong. The first character you type should be at the > >> > current insertion point, not at the one from the mouse move. >> >> Randy, >> >> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't > able >> to reproduce the problem on FreeBSD 6.3. >> >> Does the problem show up on all platforms you are working on? >> Which are these? >> >> Are there any local modifications to the libraries which I may not >> have? >> >> If it occurs only on Unix, it may be possible that a weird window >> manager interferes with the event delivery; otherwise I've got no >> good idea. If on Unix, you/we could perhaps test the behaviour >> on a different (remote) X display? >> >> Please provide more data about the problem context and how to >> reproduce it. >> >> Regards, >> >> Olaf >> >> > I'm sure the fix is easy, but I haven't been able to locate it > yet. >> > It probably has to do with the internal idea of the insertion > point >> > not getting updated properly. Note that the cursor on the screen > >> > is in the right spot, it's just that the first character gets >> > inserted into the TypeIn or TypeScript in the wrong place (i.e., > it >> > is put at the place from the mouse move, not from the last arrow > >> > key move). >> > >> > Any assistance you can provide is very much appreciated and will > go >> > a long way toward keeping Modula-3 use alive and well for this >> > project. If we can't fix this one, the customers will want to >> > re-code everything in some Microsoft language, probably C++ or > C#. >> > >> > I also have one other strange anomaly, but it is less of an issue > at >> > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all > >> > pixmaps are getting stretched vertically. Text seems to be fine > as >> > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched > out >> > of proportion. This problem has not happened on all other > platforms >> > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 > at >> > 1400x1050, etc.). Any ideas on what could be the issue? I know > >> > that 1920x1200 is a strange resolution, but it is the native >> > resolution for the M4300 laptop computer that the customer is > using. >> > I checked and the computer is set for 96dpi (normal). Perhaps > >> > there is some Trestle setting that I need to tweak on this > platform, >> > or perhaps there is a bug that needs fixing. >> > >> > Regards, >> > Randy Coleburn >> > Senior Systems Engineer >> > Scientific Research Corporation >> > >> >> >> >> -- >> 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 >> >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu > > -- 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