From dmuysers at hotmail.com Sat Mar 10 16:06:00 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 16:06:00 +0100 Subject: [M3devel] LONGINT Message-ID: It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 16:50:14 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 16:50:14 +0100 Subject: [M3devel] LONGINT In-Reply-To: <04BF2F51-1AA6-44B6-81A2-A66E5BE4494B@gmail.com> References: <04BF2F51-1AA6-44B6-81A2-A66E5BE4494B@gmail.com> Message-ID: Yes, that compiles, but looks a bit perverse since one intuitively is induced to think that the VAL source should fit the VAL destination because it is a "legal" LOOPHOLE and should be submitted to the same restrictions as the latter. From: Antony Hosking Sent: Saturday, March 10, 2012 4:32 PM To: Dirk Muysers Cc: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT Have you tried ORD(VAL(x, INTEGER)) where x is a LONGINT? I?m surprised about the second problem. Perhaps it is not yet fixed in that release. On Mar 10, 2012, at 10:06 AM, Dirk Muysers wrote: It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 17:07:16 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 17:07:16 +0100 Subject: [M3devel] ORD/VAL Message-ID: Reading once more through chapter 2.6.13 of the latest language reference, I come to the conclusion that we should have left ORD/VAL to the enumerations where they originally belonged to and have added an explicit LONG/SHORT builtin as the Oberon folks did. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Mar 10 22:22:35 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 10 Mar 2012 21:22:35 +0000 (GMT) Subject: [M3devel] LONGINT In-Reply-To: Message-ID: <1331414555.7112.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: I was reading a Embeddable Module modification to Oberon: http://www1.chapman.edu/~radenski/research/papers/module.pdf ?based on the fact of the Modules being a central concept, so making Module types, etc, but thinking in it more what about Integer.T like Word.T DEC-SRC style Module naming scheme, etc? And furthermore, what about QuadWord, etc? Let me know what do you think Thanks in advance --- El s?b, 10/3/12, Dirk Muysers escribi?: De: Dirk Muysers Asunto: [M3devel] LONGINT Para: m3devel at elegosoft.com Fecha: s?bado, 10 de marzo, 2012 10:06 It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided?the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Mar 10 23:21:41 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 10 Mar 2012 23:21:41 +0100 Subject: [M3devel] ORD/VAL In-Reply-To: References: Message-ID: Nobody is forced to use ORD/VAL "outside" of enumerations. I CHAR enumerated type? WIDECHAR? On Mar 10, 2012, at 5:07 PM, Dirk Muysers wrote: > Reading once more through chapter 2.6.13 of the latest language > reference, I come to the conclusion that we should have left ORD/VAL > to the enumerations where they originally belonged to and have > added an explicit LONG/SHORT builtin as the Oberon folks did. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 12 02:46:28 2012 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Mar 2012 18:46:28 -0700 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <7696194F-EF9E-4348-BCF4-E5216B826CCF@gmail.com> References: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com> <7696194F-EF9E-4348-BCF4-E5216B826CCF@gmail.com> Message-ID: Anyone here want some 12" Macintosh PowerPC laptops? I have at least 3. They haven't been used in months/years. - Jay >> From dabenavidesd at yahoo.es Mon Mar 12 03:37:33 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 12 Mar 2012 02:37:33 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: Message-ID: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi: what kind of laptop (mini) or sort of? What OS is it? Any special reason(s) for taking three of them? Thanks in advance. --- El dom, 11/3/12, Jay escribi?: > De: Jay > Asunto: [M3devel] 3 Macintosh PowerPC laptops? > Para: "m3devel at elegosoft.com" > Fecha: domingo, 11 de marzo, 2012 20:46 > Anyone here want some 12" Macintosh > PowerPC laptops? I have at least 3. They haven't been used > in months/years. > > - Jay > >> > From jay.krell at cornell.edu Mon Mar 12 04:37:44 2012 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Mar 2012 20:37:44 -0700 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com> 12" 3: that's how many I have found so cleaning. They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD and one can run MacOS 9. - Jay (phone) On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." wrote: > Hi: > what kind of laptop (mini) or sort of? > What OS is it? > Any special reason(s) for taking three of them? > Thanks in advance. > > --- El dom, 11/3/12, Jay escribi?: > >> De: Jay >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? >> Para: "m3devel at elegosoft.com" >> Fecha: domingo, 11 de marzo, 2012 20:46 >> Anyone here want some 12" Macintosh >> PowerPC laptops? I have at least 3. They haven't been used >> in months/years. >> >> - Jay >>>> >> From dabenavidesd at yahoo.es Mon Mar 12 20:44:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 12 Mar 2012 19:44:04 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com> Message-ID: <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi: Is it 64 bit laptop? How much does it weight? Is it light-weight? Thanks in advance --- El dom, 11/3/12, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > Para: "Daniel Alejandro Benavides D." > CC: "m3devel at elegosoft.com" , "Jay" > Fecha: domingo, 11 de marzo, 2012 22:37 > 12" > 3: that's how many I have found so cleaning. > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > and one can run MacOS 9. > > - Jay (phone) > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > wrote: > > > Hi: > > what kind of laptop (mini) or sort of? > > What OS is it? > > Any special reason(s) for taking three of them? > > Thanks in advance. > > > > --- El dom, 11/3/12, Jay > escribi?: > > > >> De: Jay > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > >> Para: "m3devel at elegosoft.com" > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > >> Anyone here want some 12" Macintosh > >> PowerPC laptops? I have at least 3. They haven't > been used > >> in months/years. > >> > >> - Jay > >>>> > >> > From jay.krell at cornell.edu Mon Mar 12 21:28:54 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Mar 2012 20:28:54 +0000 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com>, <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: I've never heard of a 64bit PowerPC laptop. - Jay > Date: Mon, 12 Mar 2012 19:44:04 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] 3 Macintosh PowerPC laptops? > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi: > Is it 64 bit laptop? > How much does it weight? Is it light-weight? > > Thanks in advance > > --- El dom, 11/3/12, Jay escribi?: > > > De: Jay > > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > > Para: "Daniel Alejandro Benavides D." > > CC: "m3devel at elegosoft.com" , "Jay" > > Fecha: domingo, 11 de marzo, 2012 22:37 > > 12" > > 3: that's how many I have found so cleaning. > > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > > and one can run MacOS 9. > > > > - Jay (phone) > > > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > > > wrote: > > > > > Hi: > > > what kind of laptop (mini) or sort of? > > > What OS is it? > > > Any special reason(s) for taking three of them? > > > Thanks in advance. > > > > > > --- El dom, 11/3/12, Jay > > escribi?: > > > > > >> De: Jay > > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > > >> Para: "m3devel at elegosoft.com" > > > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > > >> Anyone here want some 12" Macintosh > > >> PowerPC laptops? I have at least 3. They haven't > > been used > > >> in months/years. > > >> > > >> - Jay > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 13 15:57:33 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 13 Mar 2012 14:57:33 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: Message-ID: <1331650653.43835.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi: maybe in my mind or something like that is introduced by the name of Ultra-Book, or something affine. Saw some announcement on Modular computer nodes for military-aerospeace applications. Some tough machines. I have to try to see one built itself around that idea, but it's not the eighties and we're not quite there! Specially if Semiconductor fabrics are not sharing anything. But I like the idea of being ultra-thin, how thick it is as is? Thanks in advance --- El lun, 12/3/12, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] 3 Macintosh PowerPC laptops? Para: dabenavidesd at yahoo.es CC: "m3devel" Fecha: lunes, 12 de marzo, 2012 15:28 I've never heard of a 64bit PowerPC laptop. ? ?- Jay ? > Date: Mon, 12 Mar 2012 19:44:04 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] 3 Macintosh PowerPC laptops? > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi: > Is it 64 bit laptop? > How much does it weight? Is it light-weight? > > Thanks in advance > > --- El dom, 11/3/12, Jay escribi?: > > > De: Jay > > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > > Para: "Daniel Alejandro Benavides D." > > CC: "m3devel at elegosoft.com" , "Jay" > > Fecha: domingo, 11 de marzo, 2012 22:37 > > 12" > > 3: that's how many I have found so cleaning. > > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > > and one can run MacOS 9. > > > > - Jay (phone) > > > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > > > wrote: > > > > > Hi: > > > what kind of laptop (mini) or sort of? > > > What OS is it? > > > Any special reason(s) for taking three of them? > > > Thanks in advance. > > > > > > --- El dom, 11/3/12, Jay > > escribi?: > > > > > >> De: Jay > > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > > >> Para: "m3devel at elegosoft.com" > > > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > > >> Anyone here want some 12" Macintosh > > >> PowerPC laptops? I have at least 3. They haven't > > been used > > >> in months/years. > > >> > > >> - Jay > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Mar 19 18:13:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 18:13:29 +0100 Subject: [M3devel] Problem interfacing C lib Message-ID: #1 0x00000035bd8172a0 in evbuffer_search_range (buffer=0x694090, what=0x7
, len=0, start=0x0, end=0x7fffffffdbb0) at buffer.c:2441 #2 0x0000000000404a0c in Buffer__Search (t=, pattern=, from=, to=) at ../src/Buffer.m3:150 Buffer.m3:150 pos := evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, NIL, NIL); t.b is a pointer, so is chars? len is Utypes.size_t and it's value is 7. <* EXTERNAL evbuffer_search_range *> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: UNTRACED REF ptr): ptr; t is an ADDRESS, and so on? Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2010-10-04 07:24:16 configuration: /etc/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX Any ideas? TIA, dd From dabenavidesd at yahoo.es Mon Mar 19 19:27:15 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 19 Mar 2012 18:27:15 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: Message-ID: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: if chars is ADDRESS type why are you LOOPHOLE'ing it? Thanks in advance --- El lun, 19/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] Problem interfacing C lib > Para: "m3devel" > Fecha: lunes, 19 de marzo, 2012 12:13 > #1 0x00000035bd8172a0 in > evbuffer_search_range (buffer=0x694090, what=0x7
0x7 out of bounds>, len=0, start=0x0, > end=0x7fffffffdbb0) > at buffer.c:2441 > #2 0x0000000000404a0c in Buffer__Search (t= reading variable>, pattern= variable>, from=, > to=) at > ../src/Buffer.m3:150 > > Buffer.m3:150 > pos := > evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, > NIL, NIL); > > t.b is a pointer, so is chars? len is Utypes.size_t and > it's value is 7. > > <* EXTERNAL evbuffer_search_range *> > PROCEDURE search_range(buf: t; what: char_star; len: size_t; > start, end: UNTRACED REF ptr): ptr; > > t is an ADDRESS, and so on? > > Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-10-04 07:24:16 > configuration: /etc/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > > Any ideas? TIA, > dd > > From dragisha at m3w.org Mon Mar 19 23:44:20 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 23:44:20 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <520FB9AC-1CF9-414B-89CE-3A1FED4968B4@gmail.com> References: <520FB9AC-1CF9-414B-89CE-3A1FED4968B4@gmail.com> Message-ID: Tried that earlier? One of my first guesses. Same thing happens. On Mar 19, 2012, at 6:47 PM, Antony Hosking wrote: > > On Mar 19, 2012, at 1:13 PM, Dragi?a Duri? wrote: > >> #1 0x00000035bd8172a0 in evbuffer_search_range (buffer=0x694090, what=0x7
, len=0, start=0x0, end=0x7fffffffdbb0) >> at buffer.c:2441 >> #2 0x0000000000404a0c in Buffer__Search (t=, pattern=, from=, >> to=) at ../src/Buffer.m3:150 >> >> Buffer.m3:150 >> pos := evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, NIL, NIL); >> >> t.b is a pointer, so is chars? len is Utypes.size_t and it's value is 7. >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: UNTRACED REF ptr): ptr; > > I?m betting start and end should be ADDRESS, not UNTRACED REF. I am sure that they do not refer to an allocated ptr, but rather to some address within buf or char_star. Is chars an array? In which case, perhaps ADR(chars[0])? > >> >> t is an ADDRESS, and so on? >> >> Critical Mass Modula-3 version d5.9.0 >> last updated: 2010-07-21 >> compiled: 2010-10-04 07:24:16 >> configuration: /etc/cm3.cfg >> host: AMD64_LINUX >> target: AMD64_LINUX >> >> >> Any ideas? TIA, >> dd >> > From dragisha at m3w.org Mon Mar 19 23:45:02 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 23:45:02 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> I had some error before I LOOPHOLEd it. On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > if chars is ADDRESS type why are you LOOPHOLE'ing it? > Thanks in advance > > --- El lun, 19/3/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: [M3devel] Problem interfacing C lib >> Para: "m3devel" >> Fecha: lunes, 19 de marzo, 2012 12:13 >> #1 0x00000035bd8172a0 in >> evbuffer_search_range (buffer=0x694090, what=0x7
> 0x7 out of bounds>, len=0, start=0x0, >> end=0x7fffffffdbb0) >> at buffer.c:2441 >> #2 0x0000000000404a0c in Buffer__Search (t=> reading variable>, pattern=> variable>, from=, >> to=) at >> ../src/Buffer.m3:150 >> >> Buffer.m3:150 >> pos := >> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >> NIL, NIL); >> >> t.b is a pointer, so is chars? len is Utypes.size_t and >> it's value is 7. >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >> start, end: UNTRACED REF ptr): ptr; >> >> t is an ADDRESS, and so on? >> >> Critical Mass Modula-3 version d5.9.0 >> last updated: 2010-07-21 >> compiled: 2010-10-04 07:24:16 >> configuration: /etc/cm3.cfg >> host: AMD64_LINUX >> target: AMD64_LINUX >> >> >> Any ideas? TIA, >> dd >> >> From mika at async.caltech.edu Tue Mar 20 01:26:46 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 19 Mar 2012 17:26:46 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> Message-ID: <20120320002646.AF1FD1A207C@async.async.caltech.edu> What are the declarations of all the variables involved in the call? And what is the actual error? Is it a SIGBUS, SIGSEGV? =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >I had some error before I LOOPHOLEd it. > >On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> if chars is ADDRESS type why are you LOOPHOLE'ing it?=20 >> Thanks in advance >>=20 >> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 = >escribi=C3=B3: >>=20 >>> De: Dragi=C5=A1a Duri=C4=87 >>> Asunto: [M3devel] Problem interfacing C lib >>> Para: "m3devel" >>> Fecha: lunes, 19 de marzo, 2012 12:13 >>> #1 0x00000035bd8172a0 in >>> evbuffer_search_range (buffer=3D0x694090, what=3D0x7
>> 0x7 out of bounds>, len=3D0, start=3D0x0, >>> end=3D0x7fffffffdbb0) >>> at buffer.c:2441 >>> #2 0x0000000000404a0c in Buffer__Search (t=3D>> reading variable>, pattern=3D>> variable>, from=3D,=20 >>> to=3D) at >>> ../src/Buffer.m3:150 >>>=20 >>> Buffer.m3:150 >>> pos :=3D >>> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >>> NIL, NIL); >>>=20 >>> t.b is a pointer, so is chars=E2=80=A6 len is Utypes.size_t and >>> it's value is 7. >>>=20 >>> <* EXTERNAL evbuffer_search_range *> >>> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >>> start, end: UNTRACED REF ptr): ptr; >>>=20 >>> t is an ADDRESS, and so on=E2=80=A6 >>>=20 >>> Critical Mass Modula-3 version d5.9.0 >>> last updated: 2010-07-21 >>> compiled: 2010-10-04 07:24:16 >>> configuration: /etc/cm3.cfg >>> host: AMD64_LINUX >>> target: AMD64_LINUX >>>=20 >>>=20 >>> Any ideas? TIA, >>> dd >>>=20 >>>=20 From dragisha at m3w.org Tue Mar 20 07:04:58 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Mar 2012 07:04:58 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320002646.AF1FD1A207C@async.async.caltech.edu> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> <20120320002646.AF1FD1A207C@async.async.caltech.edu> Message-ID: Errorr is SIGSEGV. chars is UNTRACED REF ARRAY OF CHAR but it is lesser problem, I think. It looks like formal 'what' is not sent at all!? It's place is taken by next argument - INTEGER len (equal 0x7 in this example). One common problem I meet often (as I bind C often :) is this - address of open array argument is ot what it looks like. To be sure you are getting address of various UNTRACED REF..ARRAY.. and open array procedure arguments - use ADR(chars[0]) and do not use: LOOPHOLE(chars, ADDRESS) Of course, I tried ADR(chars[0]) :) - Same thing happened. Right now II downgraded my code to use strstr(3), but this argument passing still bugs me. dd On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > What are the declarations of all the variables involved in the call? > > And what is the actual error? Is it a SIGBUS, SIGSEGV? > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >> I had some error before I LOOPHOLEd it. >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> if chars is ADDRESS type why are you LOOPHOLE'ing it?=20 >>> Thanks in advance >>> =20 >>> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 = >> escribi=C3=B3: >>> =20 >>>> De: Dragi=C5=A1a Duri=C4=87 >>>> Asunto: [M3devel] Problem interfacing C lib >>>> Para: "m3devel" >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>> #1 0x00000035bd8172a0 in >>>> evbuffer_search_range (buffer=3D0x694090, what=3D0x7
>>> 0x7 out of bounds>, len=3D0, start=3D0x0, >>>> end=3D0x7fffffffdbb0) >>>> at buffer.c:2441 >>>> #2 0x0000000000404a0c in Buffer__Search (t=3D>>> reading variable>, pattern=3D>>> variable>, from=3D,=20 >>>> to=3D) at >>>> ../src/Buffer.m3:150 >>>> =20 >>>> Buffer.m3:150 >>>> pos :=3D >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >>>> NIL, NIL); >>>> =20 >>>> t.b is a pointer, so is chars=E2=80=A6 len is Utypes.size_t and >>>> it's value is 7. >>>> =20 >>>> <* EXTERNAL evbuffer_search_range *> >>>> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >>>> start, end: UNTRACED REF ptr): ptr; >>>> =20 >>>> t is an ADDRESS, and so on=E2=80=A6 >>>> =20 >>>> Critical Mass Modula-3 version d5.9.0 >>>> last updated: 2010-07-21 >>>> compiled: 2010-10-04 07:24:16 >>>> configuration: /etc/cm3.cfg >>>> host: AMD64_LINUX >>>> target: AMD64_LINUX >>>> =20 >>>> =20 >>>> Any ideas? TIA, >>>> dd >>>> =20 >>>> =20 From mika at async.caltech.edu Tue Mar 20 07:41:35 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 19 Mar 2012 23:41:35 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: Message-ID: <20120320064135.A5A601A207C@async.async.caltech.edu> Hmm... it looks like it's skipping the pushing of what on the stack, you mean? Very odd, I'd say...! Did you look at the assembly? =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >#1 0x00000035bd8172a0 in evbuffer_search_range (buffer=3D0x694090, = >what=3D0x7
, len=3D0, start=3D0x0, = >end=3D0x7fffffffdbb0) > at buffer.c:2441 >#2 0x0000000000404a0c in Buffer__Search (t=3D, = >pattern=3D, from=3D,=20 > to=3D) at ../src/Buffer.m3:150 > >Buffer.m3:150 > pos :=3D evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), = >len, NIL, NIL); > >t.b is a pointer, so is chars=85 len is Utypes.size_t and it's value is = >7. > ><* EXTERNAL evbuffer_search_range *> >PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: = >UNTRACED REF ptr): ptr; > >t is an ADDRESS, and so on=85 > >Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-10-04 07:24:16 > configuration: /etc/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > >Any ideas? TIA, >dd From dragisha at m3w.org Tue Mar 20 08:00:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Mar 2012 08:00:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320064135.A5A601A207C@async.async.caltech.edu> References: <20120320064135.A5A601A207C@async.async.caltech.edu> Message-ID: <378E40B0-8785-481F-A327-1C66D2B219CA@m3w.org> Yes, it is. No 'what' pushed at all, and some garbage got place in formal list, from the end.. In this case "garbage" is pointer to return value (of some RECORD type). Or it's base pointer (BP)? Can be - my assembly days were some time ago :). I did not analyze this deeper, not yet. I am in the middle of a project (aren't we always:) so I just made workaround here. dd On Mar 20, 2012, at 7:41 AM, Mika Nystrom wrote: > Hmm... it looks like it's skipping the pushing of what on the stack, you mean? > Very odd, I'd say...! > > Did you look at the assembly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 20 22:31:34 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Mar 2012 21:31:34 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: Message-ID: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I think the unchecked error lays down to: Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): it's allowed to have " ... a value of type ADDRESS to be assigned to a variable of type UNTRACED REF T. It is an unchecked runtime error if the value does not address a variable of type T." which could be reads conversely as: a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS. It is a checked runtime error if the variable does not address a variable of type .T And because because char_star is a subrange [-128 .. 127] OF INTEGER (and not ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specification. So maybe you need to change your char_star Thanks in advance --- El mar, 20/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 01:04 > Errorr is SIGSEGV. > > chars is UNTRACED REF ARRAY OF CHAR but it is lesser > problem, I think. It looks like formal 'what' is not > sent at all!? It's place is taken by next argument - INTEGER > len (equal 0x7 in this example). > > One common problem I meet often (as I bind C often :) is > this - address of open array argument is ot what it looks > like. To be sure you are getting address of various UNTRACED > REF..ARRAY.. and open array procedure arguments - use > > ADR(chars[0]) > > and do not use: > > LOOPHOLE(chars, ADDRESS) > > Of course, I tried ADR(chars[0]) :) - Same thing happened. > Right now II downgraded my code to use strstr(3), but this > argument passing still bugs me. > > dd > > > On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > > > What are the declarations of all the variables involved > in the call? > > > > And what is the actual error? Is it a SIGBUS, > SIGSEGV? > > > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >> I had some error before I LOOPHOLEd it. > >> > >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > Benavides D. wrote: > >> > >>> Hi all: > >>> if chars is ADDRESS type why are you > LOOPHOLE'ing it?=20 > >>> Thanks in advance > >>> =20 > >>> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 > > = > >> escribi=C3=B3: > >>> =20 > >>>> De: Dragi=C5=A1a Duri=C4=87 > >>>> Asunto: [M3devel] Problem interfacing C > lib > >>>> Para: "m3devel" > >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > >>>> #1 0x00000035bd8172a0 in > >>>> evbuffer_search_range (buffer=3D0x694090, > what=3D0x7
>>>> 0x7 out of bounds>, len=3D0, > start=3D0x0, > >>>> end=3D0x7fffffffdbb0) > >>>> at buffer.c:2441 > >>>> #2 0x0000000000404a0c in > Buffer__Search (t=3D >>>> reading variable>, pattern=3D reading > >>>> variable>, from=3D variable>,=20 > >>>> to=3D variable>) at > >>>> ../src/Buffer.m3:150 > >>>> =20 > >>>> Buffer.m3:150 > >>>> pos :=3D > >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > ADDRESS), len, > >>>> NIL, NIL); > >>>> =20 > >>>> t.b is a pointer, so is chars=E2=80=A6 len > is Utypes.size_t and > >>>> it's value is 7. > >>>> =20 > >>>> <* EXTERNAL evbuffer_search_range *> > >>>> PROCEDURE search_range(buf: t; what: > char_star; len: size_t; > >>>> start, end: UNTRACED REF ptr): ptr; > >>>> =20 > >>>> t is an ADDRESS, and so on=E2=80=A6 > >>>> =20 > >>>> Critical Mass Modula-3 version d5.9.0 > >>>> last updated: 2010-07-21 > >>>> compiled: 2010-10-04 07:24:16 > >>>> configuration: /etc/cm3.cfg > >>>> host: AMD64_LINUX > >>>> target: AMD64_LINUX > >>>> =20 > >>>> =20 > >>>> Any ideas? TIA, > >>>> dd > >>>> =20 > >>>> =20 > > From mika at async.caltech.edu Tue Mar 20 23:06:59 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 20 Mar 2012 15:06:59 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <20120320220659.9136A1A207C@async.async.caltech.edu> char_star is, at least in my installation UNTRACED REF [-16_7f-1 .. 16_7f] But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR However ADR(chars[0]) ought to be more or less precisely of the type char_star ... so I doubt that is the problem. I'm curious about whether the assembly code for the call changes without the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where is chars passed, in pure Modula-3 code? I don't know enough about the standard ABI of amd64 to know what the code should look like I'm afraid. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >I think the unchecked error lays down to: >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >does not address a variable of type T." > >which could be reads conversely as: > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >. It is a checked runtime error if the variable does not address a var= >iable of type .T=20 >=20 >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >ication. >So maybe you need to change your char_star > >Thanks in advance > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >=B3: > >> De: Dragi=C5=A1a Duri=C4=87 >> Asunto: Re: [M3devel] Problem interfacing C lib >> Para: "Mika Nystrom" >> CC: m3devel at elegosoft.com >> Fecha: martes, 20 de marzo, 2012 01:04 >> Errorr is SIGSEGV. >>=20 >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >> problem, I think. It looks like formal 'what' is not >> sent at all!? It's place is taken by next argument - INTEGER >> len (equal 0x7 in this example). >>=20 >> One common problem I meet often (as I bind C often :) is >> this - address of open array argument is ot what it looks >> like. To be sure you are getting address of various UNTRACED >> REF..ARRAY.. and open array procedure arguments - use=20 >>=20 >> ADR(chars[0]) >>=20 >> and do not use: >>=20 >> LOOPHOLE(chars, ADDRESS) >>=20 >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >> Right now II downgraded my code to use strstr(3), but this >> argument passing still bugs me. >>=20 >> dd >>=20 >>=20 >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>=20 >> > What are the declarations of all the variables involved >> in the call? >> >=20 >> > And what is the actual error? Is it a SIGBUS, >> SIGSEGV? >> >=20 >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >> >> I had some error before I LOOPHOLEd it. >> >>=20 >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >> Benavides D. wrote: >> >>=20 >> >>> Hi all: >> >>> if chars is ADDRESS type why are you >> LOOPHOLE'ing it?=3D20 >> >>> Thanks in advance >> >>> =3D20 >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >> >> =3D >> >> escribi=3DC3=3DB3: >> >>> =3D20 >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >> >>>> Asunto: [M3devel] Problem interfacing C >> lib >> >>>> Para: "m3devel" >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >> >>>> #1 0x00000035bd8172a0 in >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >> what=3D3D0x7
> >>>> 0x7 out of bounds>, len=3D3D0, >> start=3D3D0x0, >> >>>> end=3D3D0x7fffffffdbb0) >> >>>> at buffer.c:2441 >> >>>> #2 0x0000000000404a0c in >> Buffer__Search (t=3D3D> >>>> reading variable>, pattern=3D3D> reading >> >>>> variable>, from=3D3D> variable>,=3D20 >> >>>> to=3D3D> variable>) at >> >>>> ../src/Buffer.m3:150 >> >>>> =3D20 >> >>>> Buffer.m3:150 >> >>>> pos :=3D3D >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >> ADDRESS), len, >> >>>> NIL, NIL); >> >>>> =3D20 >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >> is Utypes.size_t and >> >>>> it's value is 7. >> >>>> =3D20 >> >>>> <* EXTERNAL evbuffer_search_range *> >> >>>> PROCEDURE search_range(buf: t; what: >> char_star; len: size_t; >> >>>> start, end: UNTRACED REF ptr): ptr; >> >>>> =3D20 >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >> >>>> =3D20 >> >>>> Critical Mass Modula-3 version d5.9.0 >> >>>> last updated: 2010-07-21 >> >>>> compiled: 2010-10-04 07:24:16 >> >>>> configuration: /etc/cm3.cfg >> >>>> host: AMD64_LINUX >> >>>> target: AMD64_LINUX >> >>>> =3D20 >> >>>> =3D20 >> >>>> Any ideas? TIA, >> >>>> dd >> >>>> =3D20 >> >>>> =3D20 >>=20 >> From dabenavidesd at yahoo.es Wed Mar 21 04:30:42 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 03:30:42 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <1332300642.47039.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: Even when types are very similar, there is still a susceptibility to hit range checking problems. This is true if you see a [-n-1 .. n] not exactly comparable with the CHAR enumeration type (not talking about representation base). So they are not subtypes of each other but also they are not subrange or included in the other as is. This problem would be ameliorated by having a range interval safe machine, not exactly amd64 :( Thanks in advance --- El mar, 20/3/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 17:06 > char_star is, at least in my > installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF > ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call > changes without > the <*EXTERNAL*> pragma... it shouldn't should > it? In which case, where > is chars passed, in pure Modula-3 code? I don't know > enough about the > standard ABI of amd64 to know what the code should look like > I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- > 61): > >it's allowed to have " ... a value of type ADDRESS to be > assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime > error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a > variable of type ADDRESS= > >. It is a checked runtime error if the variable does not > address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. > 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF > CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 > escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is > lesser > >> problem, I think. It looks like formal 'what' > is not > >> sent at all!? It's place is taken by next argument > - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often > :) is > >> this - address of open array argument is ot what it > looks > >> like. To be sure you are getting address of various > UNTRACED > >> REF..ARRAY.. and open array procedure arguments - > use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing > happened. > >> Right now II downgraded my code to use strstr(3), > but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables > involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a > SIGBUS, > >> SIGSEGV? > >> >=20 > >> > > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel > Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem > interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 > 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range > (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, > pattern=3D3D >> reading > >> >>>> variable>, from=3D3D reading > >> variable>,=3D20 > >> >>>> to=3D3D reading > >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos > :=3D3D > >> >>>> evbuffer.search_range(t.b, > LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is > chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL > evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; > what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): > ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so > on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version > d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> > From jay.krell at cornell.edu Wed Mar 21 05:35:37 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Mar 2012 04:35:37 +0000 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com>, <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: That is a bit wierd. Lots of things seem wierd at first..and wierd even at second, but often there are reasons things are how they are, and often there are barriers to change. I would expect Ctypes.char = CHAR. But I don't know why it isn't. I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character.But it isn't. It is 8 bits and will never be larger. You are really best not to interface directly to C that you didn't write and the C that you write that you interface to, you are best restricting to a subset of C. And use m3-libs/m3core/src/unix for working examples. I remember when I added "BITS FOR" in Ctypes, it broke stuff.I either didn't commit that or later removed it, leaving things as theyhave been historically. - Jay > To: dabenavidesd at yahoo.es > Date: Tue, 20 Mar 2012 15:06:59 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Problem interfacing C lib > > char_star is, at least in my installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call changes without > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where > is chars passed, in pure Modula-3 code? I don't know enough about the > standard ABI of amd64 to know what the code should look like I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= > >. It is a checked runtime error if the variable does not address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser > >> problem, I think. It looks like formal 'what' is not > >> sent at all!? It's place is taken by next argument - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often :) is > >> this - address of open array argument is ot what it looks > >> like. To be sure you are getting address of various UNTRACED > >> REF..ARRAY.. and open array procedure arguments - use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. > >> Right now II downgraded my code to use strstr(3), but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a SIGBUS, > >> SIGSEGV? > >> >=20 > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, pattern=3D3D >> reading > >> >>>> variable>, from=3D3D >> variable>,=3D20 > >> >>>> to=3D3D >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos :=3D3D > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Wed Mar 21 08:28:30 2012 From: peter.mckinna at gmail.com (Peter McKinna) Date: Wed, 21 Mar 2012 18:28:30 +1100 Subject: [M3devel] cm3 on raspberry pi Message-ID: Hi Whats the status of the arm port for cm3? Just asking since there is a lot of interest in the new raspberry pi machine, the credit card sized linux box selling for $35 Regards Peter From microcode at zoho.com Wed Mar 21 09:34:31 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Wed, 21 Mar 2012 08:34:31 +0000 Subject: [M3devel] cm3 on raspberry pi Message-ID: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> Selling but not shipping as far as I know. Is there any reason CM3 wouldn't run on it as opposed to other ARM Linux boxes? ------Original Message------ From: Peter McKinna To: m3devel at elegosoft.com Subject: [M3devel] cm3 on raspberry pi Sent: 21 Mar 2012 07:28 Hi Whats the status of the arm port for cm3? Just asking since there is a lot of interest in the new raspberry pi machine, the credit card sized linux box selling for $35 Regards Peter From dragisha at m3w.org Wed Mar 21 11:22:47 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 21 Mar 2012 11:22:47 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com>, <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). ===== struct evbuffer_ptr evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) { return evbuffer_search_range(buffer, what, len, start, NULL); } struct evbuffer_ptr evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) { On Mar 21, 2012, at 5:35 AM, Jay K wrote: > That is a bit wierd. > Lots of things seem wierd at first..and wierd even at second, > but often there are reasons things are how they are, > and often there are barriers to change. > > > I would expect Ctypes.char = CHAR. > > > But I don't know why it isn't. > > > I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. > But it isn't. It is 8 bits and will never be larger. > > > You are really best not to interface directly to C that you didn't write > and the C that you write that you interface to, you are best restricting > to a subset of C. > > > And use m3-libs/m3core/src/unix for working examples. > > > I remember when I added "BITS FOR" in Ctypes, it broke stuff. > I either didn't commit that or later removed it, leaving things as they > have been historically. > > > - Jay > > > To: dabenavidesd at yahoo.es > > Date: Tue, 20 Mar 2012 15:06:59 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Problem interfacing C lib > > > > char_star is, at least in my installation > > > > UNTRACED REF [-16_7f-1 .. 16_7f] > > > > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR > > > > However > > > > ADR(chars[0]) > > > > ought to be more or less precisely of the type char_star > > > > ... so I doubt that is the problem. > > > > I'm curious about whether the assembly code for the call changes without > > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where > > is chars passed, in pure Modula-3 code? I don't know enough about the > > standard ABI of amd64 to know what the code should look like I'm afraid. > > > > Mika > > > > "Daniel Alejandro Benavides D." writes: > > >Hi all: > > >I think the unchecked error lays down to: > > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): > > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= > > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = > > >does not address a variable of type T." > > > > > >which could be reads conversely as: > > > > > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= > > >. It is a checked runtime error if the variable does not address a var= > > >iable of type .T=20 > > >=20 > > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= > > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= > > >ication. > > >So maybe you need to change your char_star > > > > > >Thanks in advance > > > > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= > > >=B3: > > > > > >> De: Dragi=C5=A1a Duri=C4=87 > > >> Asunto: Re: [M3devel] Problem interfacing C lib > > >> Para: "Mika Nystrom" > > >> CC: m3devel at elegosoft.com > > >> Fecha: martes, 20 de marzo, 2012 01:04 > > >> Errorr is SIGSEGV. > > >>=20 > > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser > > >> problem, I think. It looks like formal 'what' is not > > >> sent at all!? It's place is taken by next argument - INTEGER > > >> len (equal 0x7 in this example). > > >>=20 > > >> One common problem I meet often (as I bind C often :) is > > >> this - address of open array argument is ot what it looks > > >> like. To be sure you are getting address of various UNTRACED > > >> REF..ARRAY.. and open array procedure arguments - use=20 > > >>=20 > > >> ADR(chars[0]) > > >>=20 > > >> and do not use: > > >>=20 > > >> LOOPHOLE(chars, ADDRESS) > > >>=20 > > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. > > >> Right now II downgraded my code to use strstr(3), but this > > >> argument passing still bugs me. > > >>=20 > > >> dd > > >>=20 > > >>=20 > > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > > >>=20 > > >> > What are the declarations of all the variables involved > > >> in the call? > > >> >=20 > > >> > And what is the actual error? Is it a SIGBUS, > > >> SIGSEGV? > > >> >=20 > > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > > >> >> I had some error before I LOOPHOLEd it. > > >> >>=20 > > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > > >> Benavides D. wrote: > > >> >>=20 > > >> >>> Hi all: > > >> >>> if chars is ADDRESS type why are you > > >> LOOPHOLE'ing it?=3D20 > > >> >>> Thanks in advance > > >> >>> =3D20 > > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 > > >> > > >> =3D > > >> >> escribi=3DC3=3DB3: > > >> >>> =3D20 > > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 > > >> >>>> Asunto: [M3devel] Problem interfacing C > > >> lib > > >> >>>> Para: "m3devel" > > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > > >> >>>> #1 0x00000035bd8172a0 in > > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, > > >> what=3D3D0x7
> >> >>>> 0x7 out of bounds>, len=3D3D0, > > >> start=3D3D0x0, > > >> >>>> end=3D3D0x7fffffffdbb0) > > >> >>>> at buffer.c:2441 > > >> >>>> #2 0x0000000000404a0c in > > >> Buffer__Search (t=3D3D > >> >>>> reading variable>, pattern=3D3D > >> reading > > >> >>>> variable>, from=3D3D > >> variable>,=3D20 > > >> >>>> to=3D3D > >> variable>) at > > >> >>>> ../src/Buffer.m3:150 > > >> >>>> =3D20 > > >> >>>> Buffer.m3:150 > > >> >>>> pos :=3D3D > > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > > >> ADDRESS), len, > > >> >>>> NIL, NIL); > > >> >>>> =3D20 > > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len > > >> is Utypes.size_t and > > >> >>>> it's value is 7. > > >> >>>> =3D20 > > >> >>>> <* EXTERNAL evbuffer_search_range *> > > >> >>>> PROCEDURE search_range(buf: t; what: > > >> char_star; len: size_t; > > >> >>>> start, end: UNTRACED REF ptr): ptr; > > >> >>>> =3D20 > > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 > > >> >>>> =3D20 > > >> >>>> Critical Mass Modula-3 version d5.9.0 > > >> >>>> last updated: 2010-07-21 > > >> >>>> compiled: 2010-10-04 07:24:16 > > >> >>>> configuration: /etc/cm3.cfg > > >> >>>> host: AMD64_LINUX > > >> >>>> target: AMD64_LINUX > > >> >>>> =3D20 > > >> >>>> =3D20 > > >> >>>> Any ideas? TIA, > > >> >>>> dd > > >> >>>> =3D20 > > >> >>>> =3D20 > > >>=20 > > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Mar 21 12:31:30 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 11:31:30 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> Message-ID: <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. I wonder if it would be easier I think to handle. In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. Thanks in advance --- El mi?, 21/3/12, microcode at zoho.com escribi?: > De: microcode at zoho.com > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 21 de marzo, 2012 03:34 > Selling but not shipping as far as I > know. Is there any reason CM3 wouldn't run on it as opposed > to other ARM Linux boxes? > > ------Original Message------ > From: Peter McKinna > To: m3devel at elegosoft.com > Subject: [M3devel] cm3 on raspberry pi > Sent: 21 Mar 2012 07:28 > > Hi > > Whats the status of the arm port for cm3? > > Just asking since there is a lot of interest in the new > raspberry pi > machine, the credit card sized linux box selling for $35 > > Regards Peter > > > From dragisha at m3w.org Wed Mar 21 13:25:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 21 Mar 2012 13:25:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <* EXTERNAL evbuffer_search *> PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; <* EXTERNAL evbuffer_search_range *> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; Tried both void_star and UNTRACED REF? On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: > Can you show your M3 interface declarations for these? > > Sent from my iPad > > On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: > >> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >> >> ===== >> struct evbuffer_ptr >> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >> { >> return evbuffer_search_range(buffer, what, len, start, NULL); >> } >> >> struct evbuffer_ptr >> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >> { >> >> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >> >>> That is a bit wierd. >>> Lots of things seem wierd at first..and wierd even at second, >>> but often there are reasons things are how they are, >>> and often there are barriers to change. >>> >>> >>> I would expect Ctypes.char = CHAR. >>> >>> >>> But I don't know why it isn't. >>> >>> >>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>> But it isn't. It is 8 bits and will never be larger. >>> >>> >>> You are really best not to interface directly to C that you didn't write >>> and the C that you write that you interface to, you are best restricting >>> to a subset of C. >>> >>> >>> And use m3-libs/m3core/src/unix for working examples. >>> >>> >>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>> I either didn't commit that or later removed it, leaving things as they >>> have been historically. >>> >>> >>> - Jay >>> >>> > To: dabenavidesd at yahoo.es >>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>> > From: mika at async.caltech.edu >>> > CC: m3devel at elegosoft.com >>> > Subject: Re: [M3devel] Problem interfacing C lib >>> > >>> > char_star is, at least in my installation >>> > >>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>> > >>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>> > >>> > However >>> > >>> > ADR(chars[0]) >>> > >>> > ought to be more or less precisely of the type char_star >>> > >>> > ... so I doubt that is the problem. >>> > >>> > I'm curious about whether the assembly code for the call changes without >>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>> > >>> > Mika >>> > >>> > "Daniel Alejandro Benavides D." writes: >>> > >Hi all: >>> > >I think the unchecked error lays down to: >>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>> > >does not address a variable of type T." >>> > > >>> > >which could be reads conversely as: >>> > > >>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>> > >. It is a checked runtime error if the variable does not address a var= >>> > >iable of type .T=20 >>> > >=20 >>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>> > >ication. >>> > >So maybe you need to change your char_star >>> > > >>> > >Thanks in advance >>> > > >>> > > >>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>> > >=B3: >>> > > >>> > >> De: Dragi=C5=A1a Duri=C4=87 >>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>> > >> Para: "Mika Nystrom" >>> > >> CC: m3devel at elegosoft.com >>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>> > >> Errorr is SIGSEGV. >>> > >>=20 >>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>> > >> problem, I think. It looks like formal 'what' is not >>> > >> sent at all!? It's place is taken by next argument - INTEGER >>> > >> len (equal 0x7 in this example). >>> > >>=20 >>> > >> One common problem I meet often (as I bind C often :) is >>> > >> this - address of open array argument is ot what it looks >>> > >> like. To be sure you are getting address of various UNTRACED >>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>> > >>=20 >>> > >> ADR(chars[0]) >>> > >>=20 >>> > >> and do not use: >>> > >>=20 >>> > >> LOOPHOLE(chars, ADDRESS) >>> > >>=20 >>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>> > >> Right now II downgraded my code to use strstr(3), but this >>> > >> argument passing still bugs me. >>> > >>=20 >>> > >> dd >>> > >>=20 >>> > >>=20 >>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>> > >>=20 >>> > >> > What are the declarations of all the variables involved >>> > >> in the call? >>> > >> >=20 >>> > >> > And what is the actual error? Is it a SIGBUS, >>> > >> SIGSEGV? >>> > >> >=20 >>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>> > >> >> I had some error before I LOOPHOLEd it. >>> > >> >>=20 >>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>> > >> Benavides D. wrote: >>> > >> >>=20 >>> > >> >>> Hi all: >>> > >> >>> if chars is ADDRESS type why are you >>> > >> LOOPHOLE'ing it?=3D20 >>> > >> >>> Thanks in advance >>> > >> >>> =3D20 >>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>> > >> >>> > >> =3D >>> > >> >> escribi=3DC3=3DB3: >>> > >> >>> =3D20 >>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>> > >> lib >>> > >> >>>> Para: "m3devel" >>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>> > >> >>>> #1 0x00000035bd8172a0 in >>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>> > >> what=3D3D0x7
>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>> > >> start=3D3D0x0, >>> > >> >>>> end=3D3D0x7fffffffdbb0) >>> > >> >>>> at buffer.c:2441 >>> > >> >>>> #2 0x0000000000404a0c in >>> > >> Buffer__Search (t=3D3D>> > >> >>>> reading variable>, pattern=3D3D>> > >> reading >>> > >> >>>> variable>, from=3D3D>> > >> variable>,=3D20 >>> > >> >>>> to=3D3D>> > >> variable>) at >>> > >> >>>> ../src/Buffer.m3:150 >>> > >> >>>> =3D20 >>> > >> >>>> Buffer.m3:150 >>> > >> >>>> pos :=3D3D >>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>> > >> ADDRESS), len, >>> > >> >>>> NIL, NIL); >>> > >> >>>> =3D20 >>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>> > >> is Utypes.size_t and >>> > >> >>>> it's value is 7. >>> > >> >>>> =3D20 >>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>> > >> >>>> PROCEDURE search_range(buf: t; what: >>> > >> char_star; len: size_t; >>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>> > >> >>>> =3D20 >>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>> > >> >>>> =3D20 >>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>> > >> >>>> last updated: 2010-07-21 >>> > >> >>>> compiled: 2010-10-04 07:24:16 >>> > >> >>>> configuration: /etc/cm3.cfg >>> > >> >>>> host: AMD64_LINUX >>> > >> >>>> target: AMD64_LINUX >>> > >> >>>> =3D20 >>> > >> >>>> =3D20 >>> > >> >>>> Any ideas? TIA, >>> > >> >>>> dd >>> > >> >>>> =3D20 >>> > >> >>>> =3D20 >>> > >>=20 >>> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Mar 21 20:32:57 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 19:32:57 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <1332358377.49563.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: What would you think of this LL (library language): http://www.ic.unicamp.br/~tomasz/projects/LL/LL.html http://www.ic.unicamp.br/~tomasz/projects/LL/LLpaper.ps.gz it looks nice, to me, it was supposed to generate Modula-3, nicer even! Thanks in advance --- El mar, 20/3/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 17:06 > char_star is, at least in my > installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF > ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call > changes without > the <*EXTERNAL*> pragma... it shouldn't should > it? In which case, where > is chars passed, in pure Modula-3 code? I don't know > enough about the > standard ABI of amd64 to know what the code should look like > I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- > 61): > >it's allowed to have " ... a value of type ADDRESS to be > assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime > error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a > variable of type ADDRESS= > >. It is a checked runtime error if the variable does not > address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. > 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF > CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 > escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is > lesser > >> problem, I think. It looks like formal 'what' > is not > >> sent at all!? It's place is taken by next argument > - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often > :) is > >> this - address of open array argument is ot what it > looks > >> like. To be sure you are getting address of various > UNTRACED > >> REF..ARRAY.. and open array procedure arguments - > use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing > happened. > >> Right now II downgraded my code to use strstr(3), > but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables > involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a > SIGBUS, > >> SIGSEGV? > >> >=20 > >> > > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel > Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem > interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 > 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range > (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, > pattern=3D3D >> reading > >> >>>> variable>, from=3D3D reading > >> variable>,=3D20 > >> >>>> to=3D3D reading > >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos > :=3D3D > >> >>>> evbuffer.search_range(t.b, > LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is > chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL > evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; > what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): > ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so > on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version > d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> > From jay.krell at cornell.edu Wed Mar 21 20:35:13 2012 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Mar 2012 12:35:13 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: Not good: don't return structs by value. Pass a pointer to where you want the result. - Jay (briefly/pocket-sized-computer-aka-phone) On Mar 21, 2012, at 5:25 AM, Dragi?a Duri? wrote: > <* EXTERNAL evbuffer_search *> > PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; > > <* EXTERNAL evbuffer_search_range *> > PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; > > Tried both void_star and UNTRACED REF? > > On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: > >> Can you show your M3 interface declarations for these? >> >> Sent from my iPad >> >> On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: >> >>> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >>> >>> ===== >>> struct evbuffer_ptr >>> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >>> { >>> return evbuffer_search_range(buffer, what, len, start, NULL); >>> } >>> >>> struct evbuffer_ptr >>> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >>> { >>> >>> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >>> >>>> That is a bit wierd. >>>> Lots of things seem wierd at first..and wierd even at second, >>>> but often there are reasons things are how they are, >>>> and often there are barriers to change. >>>> >>>> >>>> I would expect Ctypes.char = CHAR. >>>> >>>> >>>> But I don't know why it isn't. >>>> >>>> >>>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>>> But it isn't. It is 8 bits and will never be larger. >>>> >>>> >>>> You are really best not to interface directly to C that you didn't write >>>> and the C that you write that you interface to, you are best restricting >>>> to a subset of C. >>>> >>>> >>>> And use m3-libs/m3core/src/unix for working examples. >>>> >>>> >>>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>>> I either didn't commit that or later removed it, leaving things as they >>>> have been historically. >>>> >>>> >>>> - Jay >>>> >>>> > To: dabenavidesd at yahoo.es >>>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>>> > From: mika at async.caltech.edu >>>> > CC: m3devel at elegosoft.com >>>> > Subject: Re: [M3devel] Problem interfacing C lib >>>> > >>>> > char_star is, at least in my installation >>>> > >>>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>>> > >>>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>>> > >>>> > However >>>> > >>>> > ADR(chars[0]) >>>> > >>>> > ought to be more or less precisely of the type char_star >>>> > >>>> > ... so I doubt that is the problem. >>>> > >>>> > I'm curious about whether the assembly code for the call changes without >>>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>>> > >>>> > Mika >>>> > >>>> > "Daniel Alejandro Benavides D." writes: >>>> > >Hi all: >>>> > >I think the unchecked error lays down to: >>>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>>> > >does not address a variable of type T." >>>> > > >>>> > >which could be reads conversely as: >>>> > > >>>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>>> > >. It is a checked runtime error if the variable does not address a var= >>>> > >iable of type .T=20 >>>> > >=20 >>>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>>> > >ication. >>>> > >So maybe you need to change your char_star >>>> > > >>>> > >Thanks in advance >>>> > > >>>> > > >>>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>>> > >=B3: >>>> > > >>>> > >> De: Dragi=C5=A1a Duri=C4=87 >>>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>>> > >> Para: "Mika Nystrom" >>>> > >> CC: m3devel at elegosoft.com >>>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>>> > >> Errorr is SIGSEGV. >>>> > >>=20 >>>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>>> > >> problem, I think. It looks like formal 'what' is not >>>> > >> sent at all!? It's place is taken by next argument - INTEGER >>>> > >> len (equal 0x7 in this example). >>>> > >>=20 >>>> > >> One common problem I meet often (as I bind C often :) is >>>> > >> this - address of open array argument is ot what it looks >>>> > >> like. To be sure you are getting address of various UNTRACED >>>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>>> > >>=20 >>>> > >> ADR(chars[0]) >>>> > >>=20 >>>> > >> and do not use: >>>> > >>=20 >>>> > >> LOOPHOLE(chars, ADDRESS) >>>> > >>=20 >>>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>>> > >> Right now II downgraded my code to use strstr(3), but this >>>> > >> argument passing still bugs me. >>>> > >>=20 >>>> > >> dd >>>> > >>=20 >>>> > >>=20 >>>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>>> > >>=20 >>>> > >> > What are the declarations of all the variables involved >>>> > >> in the call? >>>> > >> >=20 >>>> > >> > And what is the actual error? Is it a SIGBUS, >>>> > >> SIGSEGV? >>>> > >> >=20 >>>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>>> > >> >> I had some error before I LOOPHOLEd it. >>>> > >> >>=20 >>>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>>> > >> Benavides D. wrote: >>>> > >> >>=20 >>>> > >> >>> Hi all: >>>> > >> >>> if chars is ADDRESS type why are you >>>> > >> LOOPHOLE'ing it?=3D20 >>>> > >> >>> Thanks in advance >>>> > >> >>> =3D20 >>>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>> > >> >>>> > >> =3D >>>> > >> >> escribi=3DC3=3DB3: >>>> > >> >>> =3D20 >>>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>>> > >> lib >>>> > >> >>>> Para: "m3devel" >>>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>> > >> >>>> #1 0x00000035bd8172a0 in >>>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>>> > >> what=3D3D0x7
>>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>>> > >> start=3D3D0x0, >>>> > >> >>>> end=3D3D0x7fffffffdbb0) >>>> > >> >>>> at buffer.c:2441 >>>> > >> >>>> #2 0x0000000000404a0c in >>>> > >> Buffer__Search (t=3D3D>>> > >> >>>> reading variable>, pattern=3D3D>>> > >> reading >>>> > >> >>>> variable>, from=3D3D>>> > >> variable>,=3D20 >>>> > >> >>>> to=3D3D>>> > >> variable>) at >>>> > >> >>>> ../src/Buffer.m3:150 >>>> > >> >>>> =3D20 >>>> > >> >>>> Buffer.m3:150 >>>> > >> >>>> pos :=3D3D >>>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>>> > >> ADDRESS), len, >>>> > >> >>>> NIL, NIL); >>>> > >> >>>> =3D20 >>>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>>> > >> is Utypes.size_t and >>>> > >> >>>> it's value is 7. >>>> > >> >>>> =3D20 >>>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>>> > >> >>>> PROCEDURE search_range(buf: t; what: >>>> > >> char_star; len: size_t; >>>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>>> > >> >>>> =3D20 >>>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>>> > >> >>>> =3D20 >>>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>>> > >> >>>> last updated: 2010-07-21 >>>> > >> >>>> compiled: 2010-10-04 07:24:16 >>>> > >> >>>> configuration: /etc/cm3.cfg >>>> > >> >>>> host: AMD64_LINUX >>>> > >> >>>> target: AMD64_LINUX >>>> > >> >>>> =3D20 >>>> > >> >>>> =3D20 >>>> > >> >>>> Any ideas? TIA, >>>> > >> >>>> dd >>>> > >> >>>> =3D20 >>>> > >> >>>> =3D20 >>>> > >>=20 >>>> > >> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Mar 21 23:01:07 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 21 Mar 2012 18:01:07 -0400 Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <20120321220107.GA21387@topoi.pooq.com> On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. > I wonder if it would be easier I think to handle. > In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. > The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. > Thanks in advance While we're speculating, is there any chance SPIN would run on it? -- hendrik From dabenavidesd at yahoo.es Wed Mar 21 23:27:52 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 22:27:52 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <20120321220107.GA21387@topoi.pooq.com> Message-ID: <1332368872.19833.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I think we could, but I would center my focus on a Traditional Microkernel approach e.g Workplace OS (so, you could have instead of a Unix kernel level server on top of SPIN kernel) a personality in whatever language OS (Gnu/Linux, or better to say, M3/Linux) you want, in user mode (the larger part would be rewriting of lowest level of Mach, but ARX did that before it, abstraction of everything), even I know they ported AIX to Modula-3 at some point in the project. Thanks in advance --- El mi?, 21/3/12, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 21 de marzo, 2012 17:01 > On Wed, Mar 21, 2012 at 11:31:30AM > +0000, Daniel Alejandro Benavides D. wrote: > > Hi all: > > las t I thing I heard it changed from USB stick to > credit card sized, but I wonder if the USB stick is > available in any of Models. > > I wonder if it would be easier I think to handle. > > In any case, this good stuff to test a cross compiler, > I believe it is ARM32_LINUX, or so, but it would be > something akin Android phone-likes thing. > > The other question I was wondering if we can put on it > the ARX (because RIOS OS is adapting their OS as a third > party), they have told have they can emulate the thing for > now with a VM developed for their OS. > > Thanks in advance > > While we're speculating, is there any chance SPIN would run > on it? > > -- hendrik > From dragisha at m3w.org Thu Mar 22 12:08:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 22 Mar 2012 12:08:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: I'll try it soon, but I believe you are right. That is only place in whole libevent where I met with struct return value. Everything else I tried works good. dd On Mar 21, 2012, at 8:35 PM, Jay wrote: > Not good: don't return structs by value. Pass a pointer to where you want the result. > > - Jay (briefly/pocket-sized-computer-aka-phone) > > On Mar 21, 2012, at 5:25 AM, Dragi?a Duri? wrote: > >> <* EXTERNAL evbuffer_search *> >> PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; >> >> Tried both void_star and UNTRACED REF? >> >> On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: >> >>> Can you show your M3 interface declarations for these? >>> >>> Sent from my iPad >>> >>> On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: >>> >>>> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >>>> >>>> ===== >>>> struct evbuffer_ptr >>>> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >>>> { >>>> return evbuffer_search_range(buffer, what, len, start, NULL); >>>> } >>>> >>>> struct evbuffer_ptr >>>> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >>>> { >>>> >>>> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >>>> >>>>> That is a bit wierd. >>>>> Lots of things seem wierd at first..and wierd even at second, >>>>> but often there are reasons things are how they are, >>>>> and often there are barriers to change. >>>>> >>>>> >>>>> I would expect Ctypes.char = CHAR. >>>>> >>>>> >>>>> But I don't know why it isn't. >>>>> >>>>> >>>>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>>>> But it isn't. It is 8 bits and will never be larger. >>>>> >>>>> >>>>> You are really best not to interface directly to C that you didn't write >>>>> and the C that you write that you interface to, you are best restricting >>>>> to a subset of C. >>>>> >>>>> >>>>> And use m3-libs/m3core/src/unix for working examples. >>>>> >>>>> >>>>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>>>> I either didn't commit that or later removed it, leaving things as they >>>>> have been historically. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> > To: dabenavidesd at yahoo.es >>>>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>>>> > From: mika at async.caltech.edu >>>>> > CC: m3devel at elegosoft.com >>>>> > Subject: Re: [M3devel] Problem interfacing C lib >>>>> > >>>>> > char_star is, at least in my installation >>>>> > >>>>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>>>> > >>>>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>>>> > >>>>> > However >>>>> > >>>>> > ADR(chars[0]) >>>>> > >>>>> > ought to be more or less precisely of the type char_star >>>>> > >>>>> > ... so I doubt that is the problem. >>>>> > >>>>> > I'm curious about whether the assembly code for the call changes without >>>>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>>>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>>>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>>>> > >>>>> > Mika >>>>> > >>>>> > "Daniel Alejandro Benavides D." writes: >>>>> > >Hi all: >>>>> > >I think the unchecked error lays down to: >>>>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>>>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>>>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>>>> > >does not address a variable of type T." >>>>> > > >>>>> > >which could be reads conversely as: >>>>> > > >>>>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>>>> > >. It is a checked runtime error if the variable does not address a var= >>>>> > >iable of type .T=20 >>>>> > >=20 >>>>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>>>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>>>> > >ication. >>>>> > >So maybe you need to change your char_star >>>>> > > >>>>> > >Thanks in advance >>>>> > > >>>>> > > >>>>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>>>> > >=B3: >>>>> > > >>>>> > >> De: Dragi=C5=A1a Duri=C4=87 >>>>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>>>> > >> Para: "Mika Nystrom" >>>>> > >> CC: m3devel at elegosoft.com >>>>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>>>> > >> Errorr is SIGSEGV. >>>>> > >>=20 >>>>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>>>> > >> problem, I think. It looks like formal 'what' is not >>>>> > >> sent at all!? It's place is taken by next argument - INTEGER >>>>> > >> len (equal 0x7 in this example). >>>>> > >>=20 >>>>> > >> One common problem I meet often (as I bind C often :) is >>>>> > >> this - address of open array argument is ot what it looks >>>>> > >> like. To be sure you are getting address of various UNTRACED >>>>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>>>> > >>=20 >>>>> > >> ADR(chars[0]) >>>>> > >>=20 >>>>> > >> and do not use: >>>>> > >>=20 >>>>> > >> LOOPHOLE(chars, ADDRESS) >>>>> > >>=20 >>>>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>>>> > >> Right now II downgraded my code to use strstr(3), but this >>>>> > >> argument passing still bugs me. >>>>> > >>=20 >>>>> > >> dd >>>>> > >>=20 >>>>> > >>=20 >>>>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>>>> > >>=20 >>>>> > >> > What are the declarations of all the variables involved >>>>> > >> in the call? >>>>> > >> >=20 >>>>> > >> > And what is the actual error? Is it a SIGBUS, >>>>> > >> SIGSEGV? >>>>> > >> >=20 >>>>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>>>> > >> >> I had some error before I LOOPHOLEd it. >>>>> > >> >>=20 >>>>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>>>> > >> Benavides D. wrote: >>>>> > >> >>=20 >>>>> > >> >>> Hi all: >>>>> > >> >>> if chars is ADDRESS type why are you >>>>> > >> LOOPHOLE'ing it?=3D20 >>>>> > >> >>> Thanks in advance >>>>> > >> >>> =3D20 >>>>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>>> > >> >>>>> > >> =3D >>>>> > >> >> escribi=3DC3=3DB3: >>>>> > >> >>> =3D20 >>>>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>>>> > >> lib >>>>> > >> >>>> Para: "m3devel" >>>>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>>> > >> >>>> #1 0x00000035bd8172a0 in >>>>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>>>> > >> what=3D3D0x7
>>>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>>>> > >> start=3D3D0x0, >>>>> > >> >>>> end=3D3D0x7fffffffdbb0) >>>>> > >> >>>> at buffer.c:2441 >>>>> > >> >>>> #2 0x0000000000404a0c in >>>>> > >> Buffer__Search (t=3D3D>>>> > >> >>>> reading variable>, pattern=3D3D>>>> > >> reading >>>>> > >> >>>> variable>, from=3D3D>>>> > >> variable>,=3D20 >>>>> > >> >>>> to=3D3D>>>> > >> variable>) at >>>>> > >> >>>> ../src/Buffer.m3:150 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Buffer.m3:150 >>>>> > >> >>>> pos :=3D3D >>>>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>>>> > >> ADDRESS), len, >>>>> > >> >>>> NIL, NIL); >>>>> > >> >>>> =3D20 >>>>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>>>> > >> is Utypes.size_t and >>>>> > >> >>>> it's value is 7. >>>>> > >> >>>> =3D20 >>>>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>>>> > >> >>>> PROCEDURE search_range(buf: t; what: >>>>> > >> char_star; len: size_t; >>>>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>>>> > >> >>>> =3D20 >>>>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>>>> > >> >>>> last updated: 2010-07-21 >>>>> > >> >>>> compiled: 2010-10-04 07:24:16 >>>>> > >> >>>> configuration: /etc/cm3.cfg >>>>> > >> >>>> host: AMD64_LINUX >>>>> > >> >>>> target: AMD64_LINUX >>>>> > >> >>>> =3D20 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Any ideas? TIA, >>>>> > >> >>>> dd >>>>> > >> >>>> =3D20 >>>>> > >> >>>> =3D20 >>>>> > >>=20 >>>>> > >> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Mar 22 12:08:53 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 22 Mar 2012 12:08:53 +0100 Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <20120321220107.GA21387@topoi.pooq.com> References: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> <20120321220107.GA21387@topoi.pooq.com> Message-ID: <527A0212-B595-4D2D-9126-79BF9C762F57@m3w.org> Do we have all parts of SPIN? And do we have a right to modify it, etc etc? On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel Alejandro Benavides D. wrote: >> Hi all: >> las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. >> I wonder if it would be easier I think to handle. >> In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. >> The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. >> Thanks in advance > > While we're speculating, is there any chance SPIN would run on it? > > -- hendrik From dabenavidesd at yahoo.es Thu Mar 22 13:24:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 22 Mar 2012 12:24:25 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <527A0212-B595-4D2D-9126-79BF9C762F57@m3w.org> Message-ID: <1332419065.77273.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: I think they further developed source kernel, but several parts of it like the kernel drivers are left up to each one to setup (and as far as I know, they didn't want to open the ALPHA port, but the SPINE project would replace/update that port, I mean who cares an Alpha this days, unless you had something big there). However the Unix emulation server was more advanced in the Alpha port. However DEC UNIX server would matter only to anyone with that system, anyone? Thanks in advance --- El jue, 22/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: "Hendrik Boom" > CC: m3devel at elegosoft.com > Fecha: jueves, 22 de marzo, 2012 06:08 > Do we have all parts of SPIN? And do > we have a right to modify it, etc etc? > > On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > > > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel > Alejandro Benavides D. wrote: > >> Hi all: > >> las t I thing I heard it changed from USB stick to > credit card sized, but I wonder if the USB stick is > available in any of Models. > >> I wonder if it would be easier I think to handle. > >> In any case, this good stuff to test a cross > compiler, I believe it is ARM32_LINUX, or so, but it would > be something akin Android phone-likes thing. > >> The other question I was wondering if we can put on > it the ARX (because RIOS OS is adapting their OS as a third > party), they have told have they can emulate the thing for > now with a VM developed for their OS. > >> Thanks in advance > > > > While we're speculating, is there any chance SPIN would > run on it? > > > > -- hendrik > > From dabenavidesd at yahoo.es Fri Mar 23 16:50:36 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 23 Mar 2012 15:50:36 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <1332419065.77273.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <1332517836.93069.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: And as it happens, and other OS projects have died just because of that component in their OSes. My goal would be like this (based on some suppositions of course, but I'm almost certain of the following): - Modula-3 would allows to create a development environment capable of doing the hardest work, but will easy the self-construction of: - A driver manager system or sub-system, included in the micro-kernel, e.g Mach or ARX, or SPIN - A compiler self-trusted (currently SPIN just certifies based on type-checking but not any other static or at all procedure that I know) harvesting of trust, in which Baby Modula-3 self-constructing compiler would help to improve the most interesting parts of the compiler itself. - Development of specifications from documentation *available* of controllers. - Method implementations of them being written by hand, or with some sort of hackers help. - Self-checking of the above, and more static analysis techniques. - After we develop that, then it is time to implement the rest systematically, on architecture basic features grounds, which would allows us if possible to detect from existing drivers creation of new device drivers automatically. Possible target languages are logical ones, since most of drivers are written in assembly, then why not implemented in a logical manner (a.k.a NEC's LIME). Mika you have a Scheme interpreter, what is the status of that? Thanks in advance --- El jue, 22/3/12, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: "Hendrik Boom" , "Dragi?a Duri?" > CC: m3devel at elegosoft.com > Fecha: jueves, 22 de marzo, 2012 07:24 > Hi all: > I think they further developed source kernel, but several > parts of it like the kernel drivers are left up to each one > to setup (and as far as I know, they didn't want to open the > ALPHA port, but the SPINE project would replace/update that > port, I mean who cares an Alpha this days, unless you had > something big there). However the Unix emulation server was > more advanced in the Alpha port. However DEC UNIX server > would matter only to anyone with that system, anyone? > Thanks in advance > > --- El jue, 22/3/12, Dragi?a Duri? > escribi?: > > > De: Dragi?a Duri? > > Asunto: Re: [M3devel] cm3 on raspberry pi > > Para: "Hendrik Boom" > > CC: m3devel at elegosoft.com > > Fecha: jueves, 22 de marzo, 2012 06:08 > > Do we have all parts of SPIN? And do > > we have a right to modify it, etc etc? > > > > On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > > > > > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel > > Alejandro Benavides D. wrote: > > >> Hi all: > > >> las t I thing I heard it changed from USB > stick to > > credit card sized, but I wonder if the USB stick is > > available in any of Models. > > >> I wonder if it would be easier I think to > handle. > > >> In any case, this good stuff to test a cross > > compiler, I believe it is ARM32_LINUX, or so, but it > would > > be something akin Android phone-likes thing. > > >> The other question I was wondering if we can > put on > > it the ARX (because RIOS OS is adapting their OS as a > third > > party), they have told have they can emulate the thing > for > > now with a VM developed for their OS. > > >> Thanks in advance > > > > > > While we're speculating, is there any chance SPIN > would > > run on it? > > > > > > -- hendrik > > > > > From dragisha at m3w.org Sat Mar 24 12:27:06 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 24 Mar 2012 12:27:06 +0100 Subject: [M3devel] Status of ARM_DARWIN? Message-ID: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> Anybody using it? From dragisha at m3w.org Sat Mar 24 23:12:06 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 24 Mar 2012 23:12:06 +0100 Subject: [M3devel] quake c_source, gcc -I directive Message-ID: <8312AB2C-A725-4F9D-942B-9D7DE8A48E63@m3w.org> Anybody worked out an easy method resembling import_lib() to inform C compiler where to find include files in case it is not /usr/include? Like when I am using fink on a Mac, for example. TIA, dd From dragisha at m3w.org Sun Mar 25 00:41:31 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 00:41:31 +0100 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o My question is, can I dd -I/sw/include so if my source has #include It will be found in /sw/include/event2/event.h Of course, /usr/include, for system .h's, should work at same time. dd On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: > Hi all: > I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D > But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. > > > Thanks in advance > > --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: [M3devel] quake c_source, gcc -I directive >> Para: "m3devel" >> Fecha: s?bado, 24 de marzo, 2012 17:12 >> Anybody worked out an easy method >> resembling import_lib() to inform C compiler where to find >> include files in case it is not /usr/include? Like when I am >> using fink on a Mac, for example. >> >> TIA, >> dd >> >> From dabenavidesd at yahoo.es Sun Mar 25 00:37:49 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 24 Mar 2012 23:37:49 +0000 (GMT) Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <8312AB2C-A725-4F9D-942B-9D7DE8A48E63@m3w.org> Message-ID: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. Thanks in advance --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] quake c_source, gcc -I directive > Para: "m3devel" > Fecha: s?bado, 24 de marzo, 2012 17:12 > Anybody worked out an easy method > resembling import_lib() to inform C compiler where to find > include files in case it is not /usr/include? Like when I am > using fink on a Mac, for example. > > TIA, > dd > > From dabenavidesd at yahoo.es Sun Mar 25 01:07:44 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 25 Mar 2012 00:07:44 +0000 (GMT) Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> Message-ID: <1332634064.98273.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Maybe you need to create a package for that thing there /sw/include/event and create a symbolic link to it named src and compile and ship it. Then you would import the package as everything. Wouldn't it? Thanks in advance --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] quake c_source, gcc -I directive > Para: "Daniel Alejandro Benavides D." > CC: "m3devel" > Fecha: s?bado, 24 de marzo, 2012 18:41 > c_source("file") will compile file.c > in same directory as m3makefile with that line is. And put > object in ../$TARGET/file.o > > My question is, can I dd -I/sw/include so if my source has > > #include > > It will be found in /sw/include/event2/event.h > > Of course, /usr/include, for system .h's, should work at > same time. > > dd > > > On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > I thought the c_source file had to be named in the same > way your modula-3 sources (src), but for any other purposes > like finding utilities inside your src tree src/D > > But if that's not the implementation you need but to > link against I had to actually call the var outside the > Modula-3 environment to override it in Modula-3 system > linker. > > > > > > Thanks in advance > > > > --- El s?b, 24/3/12, Dragi?a Duri? > escribi?: > > > >> De: Dragi?a Duri? > >> Asunto: [M3devel] quake c_source, gcc -I directive > >> Para: "m3devel" > >> Fecha: s?bado, 24 de marzo, 2012 17:12 > >> Anybody worked out an easy method > >> resembling import_lib() to inform C compiler where > to find > >> include files in case it is not /usr/include? Like > when I am > >> using fink on a Mac, for example. > >> > >> TIA, > >> dd > >> > >> > > From darko at darko.org Sun Mar 25 06:55:17 2012 From: darko at darko.org (Darko) Date: Sat, 24 Mar 2012 21:55:17 -0700 Subject: [M3devel] Status of ARM_DARWIN? In-Reply-To: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> References: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> Message-ID: <4925F43C-C418-4507-8038-C63408495220@darko.org> I don't think it works right now. I think native ARM_DARWIN and ARM_LINUX implementations would be a blessing given the proliferation of ARM devices, though. On 24/03/2012, at 4:27 AM, Dragi?a Duri? wrote: > Anybody using it? From dragisha at m3w.org Sun Mar 25 09:46:13 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 09:46:13 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> Message-ID: <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org> Read through Darwin.common,Unix.common? No mention. SYSTEM_LIBS is for -L dd On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: > Can you not augment the standard system .h include paths as per the m3.cfg? > > On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: > >> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o >> >> My question is, can I dd -I/sw/include so if my source has >> >> #include >> >> It will be found in /sw/include/event2/event.h >> >> Of course, /usr/include, for system .h's, should work at same time. >> >> dd >> >> >> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D >>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. >>> >>> >>> Thanks in advance >>> >>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: >>> >>>> De: Dragi?a Duri? >>>> Asunto: [M3devel] quake c_source, gcc -I directive >>>> Para: "m3devel" >>>> Fecha: s?bado, 24 de marzo, 2012 17:12 >>>> Anybody worked out an easy method >>>> resembling import_lib() to inform C compiler where to find >>>> include files in case it is not /usr/include? Like when I am >>>> using fink on a Mac, for example. >>>> >>>> TIA, >>>> dd >>>> >>>> >> > From dragisha at m3w.org Sun Mar 25 21:33:18 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 21:33:18 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org> Message-ID: I tried obvious thing :) "/Users/dragisha/m3/libevent/src/m3makefile", line 9: quake runtime error: wrong number of parameters passed to procedure c_source (expected 1, received 2) On Mar 25, 2012, at 3:49 PM, Antony Hosking wrote: > I am sure there is a way to do what you want with a simple one-liner in the m3makefile. > Anyone remember? > > On Mar 25, 2012, at 3:46 AM, Dragi?a Duri? wrote: > >> Read through Darwin.common,Unix.common? No mention. >> >> SYSTEM_LIBS is for -L >> >> dd >> >> On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: >> >>> Can you not augment the standard system .h include paths as per the m3.cfg? >>> >>> On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: >>> >>>> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o >>>> >>>> My question is, can I dd -I/sw/include so if my source has >>>> >>>> #include >>>> >>>> It will be found in /sw/include/event2/event.h >>>> >>>> Of course, /usr/include, for system .h's, should work at same time. >>>> >>>> dd >>>> >>>> >>>> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: >>>> >>>>> Hi all: >>>>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D >>>>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. >>>>> >>>>> >>>>> Thanks in advance >>>>> >>>>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: >>>>> >>>>>> De: Dragi?a Duri? >>>>>> Asunto: [M3devel] quake c_source, gcc -I directive >>>>>> Para: "m3devel" >>>>>> Fecha: s?bado, 24 de marzo, 2012 17:12 >>>>>> Anybody worked out an easy method >>>>>> resembling import_lib() to inform C compiler where to find >>>>>> include files in case it is not /usr/include? Like when I am >>>>>> using fink on a Mac, for example. >>>>>> >>>>>> TIA, >>>>>> dd >>>>>> >>>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Mar 26 04:40:15 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Mar 2012 02:40:15 +0000 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com>, <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org>, <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com>, <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org>, , Message-ID: We should support something like CFLAGS = CFLAGS & " -I/whatever" but we don't currently. ? SYSTEM_CC = SYSTEM_CC & " -I/whatever"almost works, but I don't believe generally does. - in the past, because SYSTEM_CC was readonly - currently because SYSTEM_CC is in some systems dynamically determined if/when any C code needs to be via configure_c_compiler (see cm3cfg.common) I don't know if Quake works this, way, but it'd be nice to be able to this: if defined(configure_c_compiler) previous_configure_c_compiler = configure_c_compiler else proc previous_configure_c_compiler() is end endproc configure_c_compiler() is previous_configure_c_compiler() SYSTEM_CC = SYSTEM_CC & " -I/whatever end more generally though, this should be somehow abstracted per-platform like SYSTEM_LIBS? Granted, it is kind of the same for all C compilers, the -I switch. The idea of a mult-dimensional abstraction per-library/include per-target per-host per-compiler (cc vs. gcc) is kind of annoying, esp. given that -I is pretty universial. I feel like I'm missing something though. We did have something like "CFLAGS". But I don't see it currently..I'm not looking in a smart way..maybe more later....maybe... - Jay > From: dragisha at m3w.org > Date: Sun, 25 Mar 2012 21:33:18 +0200 > To: antony.hosking at gmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quake c_source, gcc -I directive > > I tried obvious thing :) > > "/Users/dragisha/m3/libevent/src/m3makefile", line 9: quake runtime error: wrong number of parameters passed to procedure c_source (expected 1, received 2) > > > On Mar 25, 2012, at 3:49 PM, Antony Hosking wrote: > > > I am sure there is a way to do what you want with a simple one-liner in the m3makefile. > > Anyone remember? > > > > On Mar 25, 2012, at 3:46 AM, Dragi?a Duri? wrote: > > > >> Read through Darwin.common,Unix.common. No mention. > >> > >> SYSTEM_LIBS is for -L > >> > >> dd > >> > >> On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: > >> > >>> Can you not augment the standard system .h include paths as per the m3.cfg? > >>> > >>> On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: > >>> > >>>> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o > >>>> > >>>> My question is, can I dd -I/sw/include so if my source has > >>>> > >>>> #include > >>>> > >>>> It will be found in /sw/include/event2/event.h > >>>> > >>>> Of course, /usr/include, for system .h's, should work at same time. > >>>> > >>>> dd > >>>> > >>>> > >>>> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: > >>>> > >>>>> Hi all: > >>>>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D > >>>>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. > >>>>> > >>>>> > >>>>> Thanks in advance > >>>>> > >>>>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > >>>>> > >>>>>> De: Dragi?a Duri? > >>>>>> Asunto: [M3devel] quake c_source, gcc -I directive > >>>>>> Para: "m3devel" > >>>>>> Fecha: s?bado, 24 de marzo, 2012 17:12 > >>>>>> Anybody worked out an easy method > >>>>>> resembling import_lib() to inform C compiler where to find > >>>>>> include files in case it is not /usr/include? Like when I am > >>>>>> using fink on a Mac, for example. > >>>>>> > >>>>>> TIA, > >>>>>> dd > >>>>>> > >>>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Mar 26 09:04:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 26 Mar 2012 09:04:29 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com>, <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org>, <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com>, <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org>, , Message-ID: <2DC7D00F-79E4-4FFD-BCF5-71139A9D563D@m3w.org> Works on AMD64_DARWIN, and that is what I neeed. Thank you! I think we need third argument to import_lib(). dd On Mar 26, 2012, at 4:40 AM, Jay K wrote: > We should support something like > CFLAGS = CFLAGS & " -I/whatever" > > > but we don't currently. ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 16:06:00 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 16:06:00 +0100 Subject: [M3devel] LONGINT Message-ID: It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 16:50:14 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 16:50:14 +0100 Subject: [M3devel] LONGINT In-Reply-To: <04BF2F51-1AA6-44B6-81A2-A66E5BE4494B@gmail.com> References: <04BF2F51-1AA6-44B6-81A2-A66E5BE4494B@gmail.com> Message-ID: Yes, that compiles, but looks a bit perverse since one intuitively is induced to think that the VAL source should fit the VAL destination because it is a "legal" LOOPHOLE and should be submitted to the same restrictions as the latter. From: Antony Hosking Sent: Saturday, March 10, 2012 4:32 PM To: Dirk Muysers Cc: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT Have you tried ORD(VAL(x, INTEGER)) where x is a LONGINT? I?m surprised about the second problem. Perhaps it is not yet fixed in that release. On Mar 10, 2012, at 10:06 AM, Dirk Muysers wrote: It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 17:07:16 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 17:07:16 +0100 Subject: [M3devel] ORD/VAL Message-ID: Reading once more through chapter 2.6.13 of the latest language reference, I come to the conclusion that we should have left ORD/VAL to the enumerations where they originally belonged to and have added an explicit LONG/SHORT builtin as the Oberon folks did. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Mar 10 22:22:35 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 10 Mar 2012 21:22:35 +0000 (GMT) Subject: [M3devel] LONGINT In-Reply-To: Message-ID: <1331414555.7112.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: I was reading a Embeddable Module modification to Oberon: http://www1.chapman.edu/~radenski/research/papers/module.pdf ?based on the fact of the Modules being a central concept, so making Module types, etc, but thinking in it more what about Integer.T like Word.T DEC-SRC style Module naming scheme, etc? And furthermore, what about QuadWord, etc? Let me know what do you think Thanks in advance --- El s?b, 10/3/12, Dirk Muysers escribi?: De: Dirk Muysers Asunto: [M3devel] LONGINT Para: m3devel at elegosoft.com Fecha: s?bado, 10 de marzo, 2012 10:06 It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided?the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Mar 10 23:21:41 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 10 Mar 2012 23:21:41 +0100 Subject: [M3devel] ORD/VAL In-Reply-To: References: Message-ID: Nobody is forced to use ORD/VAL "outside" of enumerations. I CHAR enumerated type? WIDECHAR? On Mar 10, 2012, at 5:07 PM, Dirk Muysers wrote: > Reading once more through chapter 2.6.13 of the latest language > reference, I come to the conclusion that we should have left ORD/VAL > to the enumerations where they originally belonged to and have > added an explicit LONG/SHORT builtin as the Oberon folks did. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 12 02:46:28 2012 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Mar 2012 18:46:28 -0700 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <7696194F-EF9E-4348-BCF4-E5216B826CCF@gmail.com> References: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com> <7696194F-EF9E-4348-BCF4-E5216B826CCF@gmail.com> Message-ID: Anyone here want some 12" Macintosh PowerPC laptops? I have at least 3. They haven't been used in months/years. - Jay >> From dabenavidesd at yahoo.es Mon Mar 12 03:37:33 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 12 Mar 2012 02:37:33 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: Message-ID: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi: what kind of laptop (mini) or sort of? What OS is it? Any special reason(s) for taking three of them? Thanks in advance. --- El dom, 11/3/12, Jay escribi?: > De: Jay > Asunto: [M3devel] 3 Macintosh PowerPC laptops? > Para: "m3devel at elegosoft.com" > Fecha: domingo, 11 de marzo, 2012 20:46 > Anyone here want some 12" Macintosh > PowerPC laptops? I have at least 3. They haven't been used > in months/years. > > - Jay > >> > From jay.krell at cornell.edu Mon Mar 12 04:37:44 2012 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Mar 2012 20:37:44 -0700 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com> 12" 3: that's how many I have found so cleaning. They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD and one can run MacOS 9. - Jay (phone) On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." wrote: > Hi: > what kind of laptop (mini) or sort of? > What OS is it? > Any special reason(s) for taking three of them? > Thanks in advance. > > --- El dom, 11/3/12, Jay escribi?: > >> De: Jay >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? >> Para: "m3devel at elegosoft.com" >> Fecha: domingo, 11 de marzo, 2012 20:46 >> Anyone here want some 12" Macintosh >> PowerPC laptops? I have at least 3. They haven't been used >> in months/years. >> >> - Jay >>>> >> From dabenavidesd at yahoo.es Mon Mar 12 20:44:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 12 Mar 2012 19:44:04 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com> Message-ID: <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi: Is it 64 bit laptop? How much does it weight? Is it light-weight? Thanks in advance --- El dom, 11/3/12, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > Para: "Daniel Alejandro Benavides D." > CC: "m3devel at elegosoft.com" , "Jay" > Fecha: domingo, 11 de marzo, 2012 22:37 > 12" > 3: that's how many I have found so cleaning. > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > and one can run MacOS 9. > > - Jay (phone) > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > wrote: > > > Hi: > > what kind of laptop (mini) or sort of? > > What OS is it? > > Any special reason(s) for taking three of them? > > Thanks in advance. > > > > --- El dom, 11/3/12, Jay > escribi?: > > > >> De: Jay > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > >> Para: "m3devel at elegosoft.com" > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > >> Anyone here want some 12" Macintosh > >> PowerPC laptops? I have at least 3. They haven't > been used > >> in months/years. > >> > >> - Jay > >>>> > >> > From jay.krell at cornell.edu Mon Mar 12 21:28:54 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Mar 2012 20:28:54 +0000 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com>, <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: I've never heard of a 64bit PowerPC laptop. - Jay > Date: Mon, 12 Mar 2012 19:44:04 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] 3 Macintosh PowerPC laptops? > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi: > Is it 64 bit laptop? > How much does it weight? Is it light-weight? > > Thanks in advance > > --- El dom, 11/3/12, Jay escribi?: > > > De: Jay > > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > > Para: "Daniel Alejandro Benavides D." > > CC: "m3devel at elegosoft.com" , "Jay" > > Fecha: domingo, 11 de marzo, 2012 22:37 > > 12" > > 3: that's how many I have found so cleaning. > > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > > and one can run MacOS 9. > > > > - Jay (phone) > > > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > > > wrote: > > > > > Hi: > > > what kind of laptop (mini) or sort of? > > > What OS is it? > > > Any special reason(s) for taking three of them? > > > Thanks in advance. > > > > > > --- El dom, 11/3/12, Jay > > escribi?: > > > > > >> De: Jay > > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > > >> Para: "m3devel at elegosoft.com" > > > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > > >> Anyone here want some 12" Macintosh > > >> PowerPC laptops? I have at least 3. They haven't > > been used > > >> in months/years. > > >> > > >> - Jay > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 13 15:57:33 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 13 Mar 2012 14:57:33 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: Message-ID: <1331650653.43835.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi: maybe in my mind or something like that is introduced by the name of Ultra-Book, or something affine. Saw some announcement on Modular computer nodes for military-aerospeace applications. Some tough machines. I have to try to see one built itself around that idea, but it's not the eighties and we're not quite there! Specially if Semiconductor fabrics are not sharing anything. But I like the idea of being ultra-thin, how thick it is as is? Thanks in advance --- El lun, 12/3/12, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] 3 Macintosh PowerPC laptops? Para: dabenavidesd at yahoo.es CC: "m3devel" Fecha: lunes, 12 de marzo, 2012 15:28 I've never heard of a 64bit PowerPC laptop. ? ?- Jay ? > Date: Mon, 12 Mar 2012 19:44:04 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] 3 Macintosh PowerPC laptops? > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi: > Is it 64 bit laptop? > How much does it weight? Is it light-weight? > > Thanks in advance > > --- El dom, 11/3/12, Jay escribi?: > > > De: Jay > > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > > Para: "Daniel Alejandro Benavides D." > > CC: "m3devel at elegosoft.com" , "Jay" > > Fecha: domingo, 11 de marzo, 2012 22:37 > > 12" > > 3: that's how many I have found so cleaning. > > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > > and one can run MacOS 9. > > > > - Jay (phone) > > > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > > > wrote: > > > > > Hi: > > > what kind of laptop (mini) or sort of? > > > What OS is it? > > > Any special reason(s) for taking three of them? > > > Thanks in advance. > > > > > > --- El dom, 11/3/12, Jay > > escribi?: > > > > > >> De: Jay > > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > > >> Para: "m3devel at elegosoft.com" > > > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > > >> Anyone here want some 12" Macintosh > > >> PowerPC laptops? I have at least 3. They haven't > > been used > > >> in months/years. > > >> > > >> - Jay > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Mar 19 18:13:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 18:13:29 +0100 Subject: [M3devel] Problem interfacing C lib Message-ID: #1 0x00000035bd8172a0 in evbuffer_search_range (buffer=0x694090, what=0x7
, len=0, start=0x0, end=0x7fffffffdbb0) at buffer.c:2441 #2 0x0000000000404a0c in Buffer__Search (t=, pattern=, from=, to=) at ../src/Buffer.m3:150 Buffer.m3:150 pos := evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, NIL, NIL); t.b is a pointer, so is chars? len is Utypes.size_t and it's value is 7. <* EXTERNAL evbuffer_search_range *> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: UNTRACED REF ptr): ptr; t is an ADDRESS, and so on? Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2010-10-04 07:24:16 configuration: /etc/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX Any ideas? TIA, dd From dabenavidesd at yahoo.es Mon Mar 19 19:27:15 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 19 Mar 2012 18:27:15 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: Message-ID: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: if chars is ADDRESS type why are you LOOPHOLE'ing it? Thanks in advance --- El lun, 19/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] Problem interfacing C lib > Para: "m3devel" > Fecha: lunes, 19 de marzo, 2012 12:13 > #1 0x00000035bd8172a0 in > evbuffer_search_range (buffer=0x694090, what=0x7
0x7 out of bounds>, len=0, start=0x0, > end=0x7fffffffdbb0) > at buffer.c:2441 > #2 0x0000000000404a0c in Buffer__Search (t= reading variable>, pattern= variable>, from=, > to=) at > ../src/Buffer.m3:150 > > Buffer.m3:150 > pos := > evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, > NIL, NIL); > > t.b is a pointer, so is chars? len is Utypes.size_t and > it's value is 7. > > <* EXTERNAL evbuffer_search_range *> > PROCEDURE search_range(buf: t; what: char_star; len: size_t; > start, end: UNTRACED REF ptr): ptr; > > t is an ADDRESS, and so on? > > Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-10-04 07:24:16 > configuration: /etc/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > > Any ideas? TIA, > dd > > From dragisha at m3w.org Mon Mar 19 23:44:20 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 23:44:20 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <520FB9AC-1CF9-414B-89CE-3A1FED4968B4@gmail.com> References: <520FB9AC-1CF9-414B-89CE-3A1FED4968B4@gmail.com> Message-ID: Tried that earlier? One of my first guesses. Same thing happens. On Mar 19, 2012, at 6:47 PM, Antony Hosking wrote: > > On Mar 19, 2012, at 1:13 PM, Dragi?a Duri? wrote: > >> #1 0x00000035bd8172a0 in evbuffer_search_range (buffer=0x694090, what=0x7
, len=0, start=0x0, end=0x7fffffffdbb0) >> at buffer.c:2441 >> #2 0x0000000000404a0c in Buffer__Search (t=, pattern=, from=, >> to=) at ../src/Buffer.m3:150 >> >> Buffer.m3:150 >> pos := evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, NIL, NIL); >> >> t.b is a pointer, so is chars? len is Utypes.size_t and it's value is 7. >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: UNTRACED REF ptr): ptr; > > I?m betting start and end should be ADDRESS, not UNTRACED REF. I am sure that they do not refer to an allocated ptr, but rather to some address within buf or char_star. Is chars an array? In which case, perhaps ADR(chars[0])? > >> >> t is an ADDRESS, and so on? >> >> Critical Mass Modula-3 version d5.9.0 >> last updated: 2010-07-21 >> compiled: 2010-10-04 07:24:16 >> configuration: /etc/cm3.cfg >> host: AMD64_LINUX >> target: AMD64_LINUX >> >> >> Any ideas? TIA, >> dd >> > From dragisha at m3w.org Mon Mar 19 23:45:02 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 23:45:02 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> I had some error before I LOOPHOLEd it. On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > if chars is ADDRESS type why are you LOOPHOLE'ing it? > Thanks in advance > > --- El lun, 19/3/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: [M3devel] Problem interfacing C lib >> Para: "m3devel" >> Fecha: lunes, 19 de marzo, 2012 12:13 >> #1 0x00000035bd8172a0 in >> evbuffer_search_range (buffer=0x694090, what=0x7
> 0x7 out of bounds>, len=0, start=0x0, >> end=0x7fffffffdbb0) >> at buffer.c:2441 >> #2 0x0000000000404a0c in Buffer__Search (t=> reading variable>, pattern=> variable>, from=, >> to=) at >> ../src/Buffer.m3:150 >> >> Buffer.m3:150 >> pos := >> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >> NIL, NIL); >> >> t.b is a pointer, so is chars? len is Utypes.size_t and >> it's value is 7. >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >> start, end: UNTRACED REF ptr): ptr; >> >> t is an ADDRESS, and so on? >> >> Critical Mass Modula-3 version d5.9.0 >> last updated: 2010-07-21 >> compiled: 2010-10-04 07:24:16 >> configuration: /etc/cm3.cfg >> host: AMD64_LINUX >> target: AMD64_LINUX >> >> >> Any ideas? TIA, >> dd >> >> From mika at async.caltech.edu Tue Mar 20 01:26:46 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 19 Mar 2012 17:26:46 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> Message-ID: <20120320002646.AF1FD1A207C@async.async.caltech.edu> What are the declarations of all the variables involved in the call? And what is the actual error? Is it a SIGBUS, SIGSEGV? =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >I had some error before I LOOPHOLEd it. > >On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> if chars is ADDRESS type why are you LOOPHOLE'ing it?=20 >> Thanks in advance >>=20 >> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 = >escribi=C3=B3: >>=20 >>> De: Dragi=C5=A1a Duri=C4=87 >>> Asunto: [M3devel] Problem interfacing C lib >>> Para: "m3devel" >>> Fecha: lunes, 19 de marzo, 2012 12:13 >>> #1 0x00000035bd8172a0 in >>> evbuffer_search_range (buffer=3D0x694090, what=3D0x7
>> 0x7 out of bounds>, len=3D0, start=3D0x0, >>> end=3D0x7fffffffdbb0) >>> at buffer.c:2441 >>> #2 0x0000000000404a0c in Buffer__Search (t=3D>> reading variable>, pattern=3D>> variable>, from=3D,=20 >>> to=3D) at >>> ../src/Buffer.m3:150 >>>=20 >>> Buffer.m3:150 >>> pos :=3D >>> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >>> NIL, NIL); >>>=20 >>> t.b is a pointer, so is chars=E2=80=A6 len is Utypes.size_t and >>> it's value is 7. >>>=20 >>> <* EXTERNAL evbuffer_search_range *> >>> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >>> start, end: UNTRACED REF ptr): ptr; >>>=20 >>> t is an ADDRESS, and so on=E2=80=A6 >>>=20 >>> Critical Mass Modula-3 version d5.9.0 >>> last updated: 2010-07-21 >>> compiled: 2010-10-04 07:24:16 >>> configuration: /etc/cm3.cfg >>> host: AMD64_LINUX >>> target: AMD64_LINUX >>>=20 >>>=20 >>> Any ideas? TIA, >>> dd >>>=20 >>>=20 From dragisha at m3w.org Tue Mar 20 07:04:58 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Mar 2012 07:04:58 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320002646.AF1FD1A207C@async.async.caltech.edu> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> <20120320002646.AF1FD1A207C@async.async.caltech.edu> Message-ID: Errorr is SIGSEGV. chars is UNTRACED REF ARRAY OF CHAR but it is lesser problem, I think. It looks like formal 'what' is not sent at all!? It's place is taken by next argument - INTEGER len (equal 0x7 in this example). One common problem I meet often (as I bind C often :) is this - address of open array argument is ot what it looks like. To be sure you are getting address of various UNTRACED REF..ARRAY.. and open array procedure arguments - use ADR(chars[0]) and do not use: LOOPHOLE(chars, ADDRESS) Of course, I tried ADR(chars[0]) :) - Same thing happened. Right now II downgraded my code to use strstr(3), but this argument passing still bugs me. dd On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > What are the declarations of all the variables involved in the call? > > And what is the actual error? Is it a SIGBUS, SIGSEGV? > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >> I had some error before I LOOPHOLEd it. >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> if chars is ADDRESS type why are you LOOPHOLE'ing it?=20 >>> Thanks in advance >>> =20 >>> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 = >> escribi=C3=B3: >>> =20 >>>> De: Dragi=C5=A1a Duri=C4=87 >>>> Asunto: [M3devel] Problem interfacing C lib >>>> Para: "m3devel" >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>> #1 0x00000035bd8172a0 in >>>> evbuffer_search_range (buffer=3D0x694090, what=3D0x7
>>> 0x7 out of bounds>, len=3D0, start=3D0x0, >>>> end=3D0x7fffffffdbb0) >>>> at buffer.c:2441 >>>> #2 0x0000000000404a0c in Buffer__Search (t=3D>>> reading variable>, pattern=3D>>> variable>, from=3D,=20 >>>> to=3D) at >>>> ../src/Buffer.m3:150 >>>> =20 >>>> Buffer.m3:150 >>>> pos :=3D >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >>>> NIL, NIL); >>>> =20 >>>> t.b is a pointer, so is chars=E2=80=A6 len is Utypes.size_t and >>>> it's value is 7. >>>> =20 >>>> <* EXTERNAL evbuffer_search_range *> >>>> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >>>> start, end: UNTRACED REF ptr): ptr; >>>> =20 >>>> t is an ADDRESS, and so on=E2=80=A6 >>>> =20 >>>> Critical Mass Modula-3 version d5.9.0 >>>> last updated: 2010-07-21 >>>> compiled: 2010-10-04 07:24:16 >>>> configuration: /etc/cm3.cfg >>>> host: AMD64_LINUX >>>> target: AMD64_LINUX >>>> =20 >>>> =20 >>>> Any ideas? TIA, >>>> dd >>>> =20 >>>> =20 From mika at async.caltech.edu Tue Mar 20 07:41:35 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 19 Mar 2012 23:41:35 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: Message-ID: <20120320064135.A5A601A207C@async.async.caltech.edu> Hmm... it looks like it's skipping the pushing of what on the stack, you mean? Very odd, I'd say...! Did you look at the assembly? =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >#1 0x00000035bd8172a0 in evbuffer_search_range (buffer=3D0x694090, = >what=3D0x7
, len=3D0, start=3D0x0, = >end=3D0x7fffffffdbb0) > at buffer.c:2441 >#2 0x0000000000404a0c in Buffer__Search (t=3D, = >pattern=3D, from=3D,=20 > to=3D) at ../src/Buffer.m3:150 > >Buffer.m3:150 > pos :=3D evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), = >len, NIL, NIL); > >t.b is a pointer, so is chars=85 len is Utypes.size_t and it's value is = >7. > ><* EXTERNAL evbuffer_search_range *> >PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: = >UNTRACED REF ptr): ptr; > >t is an ADDRESS, and so on=85 > >Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-10-04 07:24:16 > configuration: /etc/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > >Any ideas? TIA, >dd From dragisha at m3w.org Tue Mar 20 08:00:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Mar 2012 08:00:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320064135.A5A601A207C@async.async.caltech.edu> References: <20120320064135.A5A601A207C@async.async.caltech.edu> Message-ID: <378E40B0-8785-481F-A327-1C66D2B219CA@m3w.org> Yes, it is. No 'what' pushed at all, and some garbage got place in formal list, from the end.. In this case "garbage" is pointer to return value (of some RECORD type). Or it's base pointer (BP)? Can be - my assembly days were some time ago :). I did not analyze this deeper, not yet. I am in the middle of a project (aren't we always:) so I just made workaround here. dd On Mar 20, 2012, at 7:41 AM, Mika Nystrom wrote: > Hmm... it looks like it's skipping the pushing of what on the stack, you mean? > Very odd, I'd say...! > > Did you look at the assembly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 20 22:31:34 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Mar 2012 21:31:34 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: Message-ID: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I think the unchecked error lays down to: Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): it's allowed to have " ... a value of type ADDRESS to be assigned to a variable of type UNTRACED REF T. It is an unchecked runtime error if the value does not address a variable of type T." which could be reads conversely as: a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS. It is a checked runtime error if the variable does not address a variable of type .T And because because char_star is a subrange [-128 .. 127] OF INTEGER (and not ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specification. So maybe you need to change your char_star Thanks in advance --- El mar, 20/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 01:04 > Errorr is SIGSEGV. > > chars is UNTRACED REF ARRAY OF CHAR but it is lesser > problem, I think. It looks like formal 'what' is not > sent at all!? It's place is taken by next argument - INTEGER > len (equal 0x7 in this example). > > One common problem I meet often (as I bind C often :) is > this - address of open array argument is ot what it looks > like. To be sure you are getting address of various UNTRACED > REF..ARRAY.. and open array procedure arguments - use > > ADR(chars[0]) > > and do not use: > > LOOPHOLE(chars, ADDRESS) > > Of course, I tried ADR(chars[0]) :) - Same thing happened. > Right now II downgraded my code to use strstr(3), but this > argument passing still bugs me. > > dd > > > On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > > > What are the declarations of all the variables involved > in the call? > > > > And what is the actual error? Is it a SIGBUS, > SIGSEGV? > > > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >> I had some error before I LOOPHOLEd it. > >> > >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > Benavides D. wrote: > >> > >>> Hi all: > >>> if chars is ADDRESS type why are you > LOOPHOLE'ing it?=20 > >>> Thanks in advance > >>> =20 > >>> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 > > = > >> escribi=C3=B3: > >>> =20 > >>>> De: Dragi=C5=A1a Duri=C4=87 > >>>> Asunto: [M3devel] Problem interfacing C > lib > >>>> Para: "m3devel" > >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > >>>> #1 0x00000035bd8172a0 in > >>>> evbuffer_search_range (buffer=3D0x694090, > what=3D0x7
>>>> 0x7 out of bounds>, len=3D0, > start=3D0x0, > >>>> end=3D0x7fffffffdbb0) > >>>> at buffer.c:2441 > >>>> #2 0x0000000000404a0c in > Buffer__Search (t=3D >>>> reading variable>, pattern=3D reading > >>>> variable>, from=3D variable>,=20 > >>>> to=3D variable>) at > >>>> ../src/Buffer.m3:150 > >>>> =20 > >>>> Buffer.m3:150 > >>>> pos :=3D > >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > ADDRESS), len, > >>>> NIL, NIL); > >>>> =20 > >>>> t.b is a pointer, so is chars=E2=80=A6 len > is Utypes.size_t and > >>>> it's value is 7. > >>>> =20 > >>>> <* EXTERNAL evbuffer_search_range *> > >>>> PROCEDURE search_range(buf: t; what: > char_star; len: size_t; > >>>> start, end: UNTRACED REF ptr): ptr; > >>>> =20 > >>>> t is an ADDRESS, and so on=E2=80=A6 > >>>> =20 > >>>> Critical Mass Modula-3 version d5.9.0 > >>>> last updated: 2010-07-21 > >>>> compiled: 2010-10-04 07:24:16 > >>>> configuration: /etc/cm3.cfg > >>>> host: AMD64_LINUX > >>>> target: AMD64_LINUX > >>>> =20 > >>>> =20 > >>>> Any ideas? TIA, > >>>> dd > >>>> =20 > >>>> =20 > > From mika at async.caltech.edu Tue Mar 20 23:06:59 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 20 Mar 2012 15:06:59 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <20120320220659.9136A1A207C@async.async.caltech.edu> char_star is, at least in my installation UNTRACED REF [-16_7f-1 .. 16_7f] But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR However ADR(chars[0]) ought to be more or less precisely of the type char_star ... so I doubt that is the problem. I'm curious about whether the assembly code for the call changes without the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where is chars passed, in pure Modula-3 code? I don't know enough about the standard ABI of amd64 to know what the code should look like I'm afraid. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >I think the unchecked error lays down to: >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >does not address a variable of type T." > >which could be reads conversely as: > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >. It is a checked runtime error if the variable does not address a var= >iable of type .T=20 >=20 >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >ication. >So maybe you need to change your char_star > >Thanks in advance > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >=B3: > >> De: Dragi=C5=A1a Duri=C4=87 >> Asunto: Re: [M3devel] Problem interfacing C lib >> Para: "Mika Nystrom" >> CC: m3devel at elegosoft.com >> Fecha: martes, 20 de marzo, 2012 01:04 >> Errorr is SIGSEGV. >>=20 >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >> problem, I think. It looks like formal 'what' is not >> sent at all!? It's place is taken by next argument - INTEGER >> len (equal 0x7 in this example). >>=20 >> One common problem I meet often (as I bind C often :) is >> this - address of open array argument is ot what it looks >> like. To be sure you are getting address of various UNTRACED >> REF..ARRAY.. and open array procedure arguments - use=20 >>=20 >> ADR(chars[0]) >>=20 >> and do not use: >>=20 >> LOOPHOLE(chars, ADDRESS) >>=20 >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >> Right now II downgraded my code to use strstr(3), but this >> argument passing still bugs me. >>=20 >> dd >>=20 >>=20 >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>=20 >> > What are the declarations of all the variables involved >> in the call? >> >=20 >> > And what is the actual error? Is it a SIGBUS, >> SIGSEGV? >> >=20 >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >> >> I had some error before I LOOPHOLEd it. >> >>=20 >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >> Benavides D. wrote: >> >>=20 >> >>> Hi all: >> >>> if chars is ADDRESS type why are you >> LOOPHOLE'ing it?=3D20 >> >>> Thanks in advance >> >>> =3D20 >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >> >> =3D >> >> escribi=3DC3=3DB3: >> >>> =3D20 >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >> >>>> Asunto: [M3devel] Problem interfacing C >> lib >> >>>> Para: "m3devel" >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >> >>>> #1 0x00000035bd8172a0 in >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >> what=3D3D0x7
> >>>> 0x7 out of bounds>, len=3D3D0, >> start=3D3D0x0, >> >>>> end=3D3D0x7fffffffdbb0) >> >>>> at buffer.c:2441 >> >>>> #2 0x0000000000404a0c in >> Buffer__Search (t=3D3D> >>>> reading variable>, pattern=3D3D> reading >> >>>> variable>, from=3D3D> variable>,=3D20 >> >>>> to=3D3D> variable>) at >> >>>> ../src/Buffer.m3:150 >> >>>> =3D20 >> >>>> Buffer.m3:150 >> >>>> pos :=3D3D >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >> ADDRESS), len, >> >>>> NIL, NIL); >> >>>> =3D20 >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >> is Utypes.size_t and >> >>>> it's value is 7. >> >>>> =3D20 >> >>>> <* EXTERNAL evbuffer_search_range *> >> >>>> PROCEDURE search_range(buf: t; what: >> char_star; len: size_t; >> >>>> start, end: UNTRACED REF ptr): ptr; >> >>>> =3D20 >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >> >>>> =3D20 >> >>>> Critical Mass Modula-3 version d5.9.0 >> >>>> last updated: 2010-07-21 >> >>>> compiled: 2010-10-04 07:24:16 >> >>>> configuration: /etc/cm3.cfg >> >>>> host: AMD64_LINUX >> >>>> target: AMD64_LINUX >> >>>> =3D20 >> >>>> =3D20 >> >>>> Any ideas? TIA, >> >>>> dd >> >>>> =3D20 >> >>>> =3D20 >>=20 >> From dabenavidesd at yahoo.es Wed Mar 21 04:30:42 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 03:30:42 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <1332300642.47039.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: Even when types are very similar, there is still a susceptibility to hit range checking problems. This is true if you see a [-n-1 .. n] not exactly comparable with the CHAR enumeration type (not talking about representation base). So they are not subtypes of each other but also they are not subrange or included in the other as is. This problem would be ameliorated by having a range interval safe machine, not exactly amd64 :( Thanks in advance --- El mar, 20/3/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 17:06 > char_star is, at least in my > installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF > ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call > changes without > the <*EXTERNAL*> pragma... it shouldn't should > it? In which case, where > is chars passed, in pure Modula-3 code? I don't know > enough about the > standard ABI of amd64 to know what the code should look like > I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- > 61): > >it's allowed to have " ... a value of type ADDRESS to be > assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime > error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a > variable of type ADDRESS= > >. It is a checked runtime error if the variable does not > address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. > 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF > CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 > escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is > lesser > >> problem, I think. It looks like formal 'what' > is not > >> sent at all!? It's place is taken by next argument > - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often > :) is > >> this - address of open array argument is ot what it > looks > >> like. To be sure you are getting address of various > UNTRACED > >> REF..ARRAY.. and open array procedure arguments - > use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing > happened. > >> Right now II downgraded my code to use strstr(3), > but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables > involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a > SIGBUS, > >> SIGSEGV? > >> >=20 > >> > > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel > Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem > interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 > 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range > (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, > pattern=3D3D >> reading > >> >>>> variable>, from=3D3D reading > >> variable>,=3D20 > >> >>>> to=3D3D reading > >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos > :=3D3D > >> >>>> evbuffer.search_range(t.b, > LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is > chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL > evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; > what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): > ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so > on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version > d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> > From jay.krell at cornell.edu Wed Mar 21 05:35:37 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Mar 2012 04:35:37 +0000 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com>, <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: That is a bit wierd. Lots of things seem wierd at first..and wierd even at second, but often there are reasons things are how they are, and often there are barriers to change. I would expect Ctypes.char = CHAR. But I don't know why it isn't. I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character.But it isn't. It is 8 bits and will never be larger. You are really best not to interface directly to C that you didn't write and the C that you write that you interface to, you are best restricting to a subset of C. And use m3-libs/m3core/src/unix for working examples. I remember when I added "BITS FOR" in Ctypes, it broke stuff.I either didn't commit that or later removed it, leaving things as theyhave been historically. - Jay > To: dabenavidesd at yahoo.es > Date: Tue, 20 Mar 2012 15:06:59 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Problem interfacing C lib > > char_star is, at least in my installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call changes without > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where > is chars passed, in pure Modula-3 code? I don't know enough about the > standard ABI of amd64 to know what the code should look like I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= > >. It is a checked runtime error if the variable does not address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser > >> problem, I think. It looks like formal 'what' is not > >> sent at all!? It's place is taken by next argument - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often :) is > >> this - address of open array argument is ot what it looks > >> like. To be sure you are getting address of various UNTRACED > >> REF..ARRAY.. and open array procedure arguments - use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. > >> Right now II downgraded my code to use strstr(3), but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a SIGBUS, > >> SIGSEGV? > >> >=20 > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, pattern=3D3D >> reading > >> >>>> variable>, from=3D3D >> variable>,=3D20 > >> >>>> to=3D3D >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos :=3D3D > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Wed Mar 21 08:28:30 2012 From: peter.mckinna at gmail.com (Peter McKinna) Date: Wed, 21 Mar 2012 18:28:30 +1100 Subject: [M3devel] cm3 on raspberry pi Message-ID: Hi Whats the status of the arm port for cm3? Just asking since there is a lot of interest in the new raspberry pi machine, the credit card sized linux box selling for $35 Regards Peter From microcode at zoho.com Wed Mar 21 09:34:31 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Wed, 21 Mar 2012 08:34:31 +0000 Subject: [M3devel] cm3 on raspberry pi Message-ID: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> Selling but not shipping as far as I know. Is there any reason CM3 wouldn't run on it as opposed to other ARM Linux boxes? ------Original Message------ From: Peter McKinna To: m3devel at elegosoft.com Subject: [M3devel] cm3 on raspberry pi Sent: 21 Mar 2012 07:28 Hi Whats the status of the arm port for cm3? Just asking since there is a lot of interest in the new raspberry pi machine, the credit card sized linux box selling for $35 Regards Peter From dragisha at m3w.org Wed Mar 21 11:22:47 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 21 Mar 2012 11:22:47 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com>, <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). ===== struct evbuffer_ptr evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) { return evbuffer_search_range(buffer, what, len, start, NULL); } struct evbuffer_ptr evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) { On Mar 21, 2012, at 5:35 AM, Jay K wrote: > That is a bit wierd. > Lots of things seem wierd at first..and wierd even at second, > but often there are reasons things are how they are, > and often there are barriers to change. > > > I would expect Ctypes.char = CHAR. > > > But I don't know why it isn't. > > > I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. > But it isn't. It is 8 bits and will never be larger. > > > You are really best not to interface directly to C that you didn't write > and the C that you write that you interface to, you are best restricting > to a subset of C. > > > And use m3-libs/m3core/src/unix for working examples. > > > I remember when I added "BITS FOR" in Ctypes, it broke stuff. > I either didn't commit that or later removed it, leaving things as they > have been historically. > > > - Jay > > > To: dabenavidesd at yahoo.es > > Date: Tue, 20 Mar 2012 15:06:59 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Problem interfacing C lib > > > > char_star is, at least in my installation > > > > UNTRACED REF [-16_7f-1 .. 16_7f] > > > > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR > > > > However > > > > ADR(chars[0]) > > > > ought to be more or less precisely of the type char_star > > > > ... so I doubt that is the problem. > > > > I'm curious about whether the assembly code for the call changes without > > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where > > is chars passed, in pure Modula-3 code? I don't know enough about the > > standard ABI of amd64 to know what the code should look like I'm afraid. > > > > Mika > > > > "Daniel Alejandro Benavides D." writes: > > >Hi all: > > >I think the unchecked error lays down to: > > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): > > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= > > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = > > >does not address a variable of type T." > > > > > >which could be reads conversely as: > > > > > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= > > >. It is a checked runtime error if the variable does not address a var= > > >iable of type .T=20 > > >=20 > > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= > > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= > > >ication. > > >So maybe you need to change your char_star > > > > > >Thanks in advance > > > > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= > > >=B3: > > > > > >> De: Dragi=C5=A1a Duri=C4=87 > > >> Asunto: Re: [M3devel] Problem interfacing C lib > > >> Para: "Mika Nystrom" > > >> CC: m3devel at elegosoft.com > > >> Fecha: martes, 20 de marzo, 2012 01:04 > > >> Errorr is SIGSEGV. > > >>=20 > > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser > > >> problem, I think. It looks like formal 'what' is not > > >> sent at all!? It's place is taken by next argument - INTEGER > > >> len (equal 0x7 in this example). > > >>=20 > > >> One common problem I meet often (as I bind C often :) is > > >> this - address of open array argument is ot what it looks > > >> like. To be sure you are getting address of various UNTRACED > > >> REF..ARRAY.. and open array procedure arguments - use=20 > > >>=20 > > >> ADR(chars[0]) > > >>=20 > > >> and do not use: > > >>=20 > > >> LOOPHOLE(chars, ADDRESS) > > >>=20 > > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. > > >> Right now II downgraded my code to use strstr(3), but this > > >> argument passing still bugs me. > > >>=20 > > >> dd > > >>=20 > > >>=20 > > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > > >>=20 > > >> > What are the declarations of all the variables involved > > >> in the call? > > >> >=20 > > >> > And what is the actual error? Is it a SIGBUS, > > >> SIGSEGV? > > >> >=20 > > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > > >> >> I had some error before I LOOPHOLEd it. > > >> >>=20 > > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > > >> Benavides D. wrote: > > >> >>=20 > > >> >>> Hi all: > > >> >>> if chars is ADDRESS type why are you > > >> LOOPHOLE'ing it?=3D20 > > >> >>> Thanks in advance > > >> >>> =3D20 > > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 > > >> > > >> =3D > > >> >> escribi=3DC3=3DB3: > > >> >>> =3D20 > > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 > > >> >>>> Asunto: [M3devel] Problem interfacing C > > >> lib > > >> >>>> Para: "m3devel" > > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > > >> >>>> #1 0x00000035bd8172a0 in > > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, > > >> what=3D3D0x7
> >> >>>> 0x7 out of bounds>, len=3D3D0, > > >> start=3D3D0x0, > > >> >>>> end=3D3D0x7fffffffdbb0) > > >> >>>> at buffer.c:2441 > > >> >>>> #2 0x0000000000404a0c in > > >> Buffer__Search (t=3D3D > >> >>>> reading variable>, pattern=3D3D > >> reading > > >> >>>> variable>, from=3D3D > >> variable>,=3D20 > > >> >>>> to=3D3D > >> variable>) at > > >> >>>> ../src/Buffer.m3:150 > > >> >>>> =3D20 > > >> >>>> Buffer.m3:150 > > >> >>>> pos :=3D3D > > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > > >> ADDRESS), len, > > >> >>>> NIL, NIL); > > >> >>>> =3D20 > > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len > > >> is Utypes.size_t and > > >> >>>> it's value is 7. > > >> >>>> =3D20 > > >> >>>> <* EXTERNAL evbuffer_search_range *> > > >> >>>> PROCEDURE search_range(buf: t; what: > > >> char_star; len: size_t; > > >> >>>> start, end: UNTRACED REF ptr): ptr; > > >> >>>> =3D20 > > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 > > >> >>>> =3D20 > > >> >>>> Critical Mass Modula-3 version d5.9.0 > > >> >>>> last updated: 2010-07-21 > > >> >>>> compiled: 2010-10-04 07:24:16 > > >> >>>> configuration: /etc/cm3.cfg > > >> >>>> host: AMD64_LINUX > > >> >>>> target: AMD64_LINUX > > >> >>>> =3D20 > > >> >>>> =3D20 > > >> >>>> Any ideas? TIA, > > >> >>>> dd > > >> >>>> =3D20 > > >> >>>> =3D20 > > >>=20 > > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Mar 21 12:31:30 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 11:31:30 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> Message-ID: <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. I wonder if it would be easier I think to handle. In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. Thanks in advance --- El mi?, 21/3/12, microcode at zoho.com escribi?: > De: microcode at zoho.com > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 21 de marzo, 2012 03:34 > Selling but not shipping as far as I > know. Is there any reason CM3 wouldn't run on it as opposed > to other ARM Linux boxes? > > ------Original Message------ > From: Peter McKinna > To: m3devel at elegosoft.com > Subject: [M3devel] cm3 on raspberry pi > Sent: 21 Mar 2012 07:28 > > Hi > > Whats the status of the arm port for cm3? > > Just asking since there is a lot of interest in the new > raspberry pi > machine, the credit card sized linux box selling for $35 > > Regards Peter > > > From dragisha at m3w.org Wed Mar 21 13:25:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 21 Mar 2012 13:25:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <* EXTERNAL evbuffer_search *> PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; <* EXTERNAL evbuffer_search_range *> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; Tried both void_star and UNTRACED REF? On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: > Can you show your M3 interface declarations for these? > > Sent from my iPad > > On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: > >> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >> >> ===== >> struct evbuffer_ptr >> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >> { >> return evbuffer_search_range(buffer, what, len, start, NULL); >> } >> >> struct evbuffer_ptr >> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >> { >> >> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >> >>> That is a bit wierd. >>> Lots of things seem wierd at first..and wierd even at second, >>> but often there are reasons things are how they are, >>> and often there are barriers to change. >>> >>> >>> I would expect Ctypes.char = CHAR. >>> >>> >>> But I don't know why it isn't. >>> >>> >>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>> But it isn't. It is 8 bits and will never be larger. >>> >>> >>> You are really best not to interface directly to C that you didn't write >>> and the C that you write that you interface to, you are best restricting >>> to a subset of C. >>> >>> >>> And use m3-libs/m3core/src/unix for working examples. >>> >>> >>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>> I either didn't commit that or later removed it, leaving things as they >>> have been historically. >>> >>> >>> - Jay >>> >>> > To: dabenavidesd at yahoo.es >>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>> > From: mika at async.caltech.edu >>> > CC: m3devel at elegosoft.com >>> > Subject: Re: [M3devel] Problem interfacing C lib >>> > >>> > char_star is, at least in my installation >>> > >>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>> > >>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>> > >>> > However >>> > >>> > ADR(chars[0]) >>> > >>> > ought to be more or less precisely of the type char_star >>> > >>> > ... so I doubt that is the problem. >>> > >>> > I'm curious about whether the assembly code for the call changes without >>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>> > >>> > Mika >>> > >>> > "Daniel Alejandro Benavides D." writes: >>> > >Hi all: >>> > >I think the unchecked error lays down to: >>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>> > >does not address a variable of type T." >>> > > >>> > >which could be reads conversely as: >>> > > >>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>> > >. It is a checked runtime error if the variable does not address a var= >>> > >iable of type .T=20 >>> > >=20 >>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>> > >ication. >>> > >So maybe you need to change your char_star >>> > > >>> > >Thanks in advance >>> > > >>> > > >>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>> > >=B3: >>> > > >>> > >> De: Dragi=C5=A1a Duri=C4=87 >>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>> > >> Para: "Mika Nystrom" >>> > >> CC: m3devel at elegosoft.com >>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>> > >> Errorr is SIGSEGV. >>> > >>=20 >>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>> > >> problem, I think. It looks like formal 'what' is not >>> > >> sent at all!? It's place is taken by next argument - INTEGER >>> > >> len (equal 0x7 in this example). >>> > >>=20 >>> > >> One common problem I meet often (as I bind C often :) is >>> > >> this - address of open array argument is ot what it looks >>> > >> like. To be sure you are getting address of various UNTRACED >>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>> > >>=20 >>> > >> ADR(chars[0]) >>> > >>=20 >>> > >> and do not use: >>> > >>=20 >>> > >> LOOPHOLE(chars, ADDRESS) >>> > >>=20 >>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>> > >> Right now II downgraded my code to use strstr(3), but this >>> > >> argument passing still bugs me. >>> > >>=20 >>> > >> dd >>> > >>=20 >>> > >>=20 >>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>> > >>=20 >>> > >> > What are the declarations of all the variables involved >>> > >> in the call? >>> > >> >=20 >>> > >> > And what is the actual error? Is it a SIGBUS, >>> > >> SIGSEGV? >>> > >> >=20 >>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>> > >> >> I had some error before I LOOPHOLEd it. >>> > >> >>=20 >>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>> > >> Benavides D. wrote: >>> > >> >>=20 >>> > >> >>> Hi all: >>> > >> >>> if chars is ADDRESS type why are you >>> > >> LOOPHOLE'ing it?=3D20 >>> > >> >>> Thanks in advance >>> > >> >>> =3D20 >>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>> > >> >>> > >> =3D >>> > >> >> escribi=3DC3=3DB3: >>> > >> >>> =3D20 >>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>> > >> lib >>> > >> >>>> Para: "m3devel" >>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>> > >> >>>> #1 0x00000035bd8172a0 in >>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>> > >> what=3D3D0x7
>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>> > >> start=3D3D0x0, >>> > >> >>>> end=3D3D0x7fffffffdbb0) >>> > >> >>>> at buffer.c:2441 >>> > >> >>>> #2 0x0000000000404a0c in >>> > >> Buffer__Search (t=3D3D>> > >> >>>> reading variable>, pattern=3D3D>> > >> reading >>> > >> >>>> variable>, from=3D3D>> > >> variable>,=3D20 >>> > >> >>>> to=3D3D>> > >> variable>) at >>> > >> >>>> ../src/Buffer.m3:150 >>> > >> >>>> =3D20 >>> > >> >>>> Buffer.m3:150 >>> > >> >>>> pos :=3D3D >>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>> > >> ADDRESS), len, >>> > >> >>>> NIL, NIL); >>> > >> >>>> =3D20 >>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>> > >> is Utypes.size_t and >>> > >> >>>> it's value is 7. >>> > >> >>>> =3D20 >>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>> > >> >>>> PROCEDURE search_range(buf: t; what: >>> > >> char_star; len: size_t; >>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>> > >> >>>> =3D20 >>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>> > >> >>>> =3D20 >>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>> > >> >>>> last updated: 2010-07-21 >>> > >> >>>> compiled: 2010-10-04 07:24:16 >>> > >> >>>> configuration: /etc/cm3.cfg >>> > >> >>>> host: AMD64_LINUX >>> > >> >>>> target: AMD64_LINUX >>> > >> >>>> =3D20 >>> > >> >>>> =3D20 >>> > >> >>>> Any ideas? TIA, >>> > >> >>>> dd >>> > >> >>>> =3D20 >>> > >> >>>> =3D20 >>> > >>=20 >>> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Mar 21 20:32:57 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 19:32:57 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <1332358377.49563.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: What would you think of this LL (library language): http://www.ic.unicamp.br/~tomasz/projects/LL/LL.html http://www.ic.unicamp.br/~tomasz/projects/LL/LLpaper.ps.gz it looks nice, to me, it was supposed to generate Modula-3, nicer even! Thanks in advance --- El mar, 20/3/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 17:06 > char_star is, at least in my > installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF > ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call > changes without > the <*EXTERNAL*> pragma... it shouldn't should > it? In which case, where > is chars passed, in pure Modula-3 code? I don't know > enough about the > standard ABI of amd64 to know what the code should look like > I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- > 61): > >it's allowed to have " ... a value of type ADDRESS to be > assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime > error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a > variable of type ADDRESS= > >. It is a checked runtime error if the variable does not > address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. > 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF > CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 > escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is > lesser > >> problem, I think. It looks like formal 'what' > is not > >> sent at all!? It's place is taken by next argument > - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often > :) is > >> this - address of open array argument is ot what it > looks > >> like. To be sure you are getting address of various > UNTRACED > >> REF..ARRAY.. and open array procedure arguments - > use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing > happened. > >> Right now II downgraded my code to use strstr(3), > but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables > involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a > SIGBUS, > >> SIGSEGV? > >> >=20 > >> > > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel > Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem > interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 > 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range > (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, > pattern=3D3D >> reading > >> >>>> variable>, from=3D3D reading > >> variable>,=3D20 > >> >>>> to=3D3D reading > >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos > :=3D3D > >> >>>> evbuffer.search_range(t.b, > LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is > chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL > evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; > what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): > ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so > on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version > d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> > From jay.krell at cornell.edu Wed Mar 21 20:35:13 2012 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Mar 2012 12:35:13 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: Not good: don't return structs by value. Pass a pointer to where you want the result. - Jay (briefly/pocket-sized-computer-aka-phone) On Mar 21, 2012, at 5:25 AM, Dragi?a Duri? wrote: > <* EXTERNAL evbuffer_search *> > PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; > > <* EXTERNAL evbuffer_search_range *> > PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; > > Tried both void_star and UNTRACED REF? > > On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: > >> Can you show your M3 interface declarations for these? >> >> Sent from my iPad >> >> On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: >> >>> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >>> >>> ===== >>> struct evbuffer_ptr >>> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >>> { >>> return evbuffer_search_range(buffer, what, len, start, NULL); >>> } >>> >>> struct evbuffer_ptr >>> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >>> { >>> >>> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >>> >>>> That is a bit wierd. >>>> Lots of things seem wierd at first..and wierd even at second, >>>> but often there are reasons things are how they are, >>>> and often there are barriers to change. >>>> >>>> >>>> I would expect Ctypes.char = CHAR. >>>> >>>> >>>> But I don't know why it isn't. >>>> >>>> >>>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>>> But it isn't. It is 8 bits and will never be larger. >>>> >>>> >>>> You are really best not to interface directly to C that you didn't write >>>> and the C that you write that you interface to, you are best restricting >>>> to a subset of C. >>>> >>>> >>>> And use m3-libs/m3core/src/unix for working examples. >>>> >>>> >>>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>>> I either didn't commit that or later removed it, leaving things as they >>>> have been historically. >>>> >>>> >>>> - Jay >>>> >>>> > To: dabenavidesd at yahoo.es >>>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>>> > From: mika at async.caltech.edu >>>> > CC: m3devel at elegosoft.com >>>> > Subject: Re: [M3devel] Problem interfacing C lib >>>> > >>>> > char_star is, at least in my installation >>>> > >>>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>>> > >>>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>>> > >>>> > However >>>> > >>>> > ADR(chars[0]) >>>> > >>>> > ought to be more or less precisely of the type char_star >>>> > >>>> > ... so I doubt that is the problem. >>>> > >>>> > I'm curious about whether the assembly code for the call changes without >>>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>>> > >>>> > Mika >>>> > >>>> > "Daniel Alejandro Benavides D." writes: >>>> > >Hi all: >>>> > >I think the unchecked error lays down to: >>>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>>> > >does not address a variable of type T." >>>> > > >>>> > >which could be reads conversely as: >>>> > > >>>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>>> > >. It is a checked runtime error if the variable does not address a var= >>>> > >iable of type .T=20 >>>> > >=20 >>>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>>> > >ication. >>>> > >So maybe you need to change your char_star >>>> > > >>>> > >Thanks in advance >>>> > > >>>> > > >>>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>>> > >=B3: >>>> > > >>>> > >> De: Dragi=C5=A1a Duri=C4=87 >>>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>>> > >> Para: "Mika Nystrom" >>>> > >> CC: m3devel at elegosoft.com >>>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>>> > >> Errorr is SIGSEGV. >>>> > >>=20 >>>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>>> > >> problem, I think. It looks like formal 'what' is not >>>> > >> sent at all!? It's place is taken by next argument - INTEGER >>>> > >> len (equal 0x7 in this example). >>>> > >>=20 >>>> > >> One common problem I meet often (as I bind C often :) is >>>> > >> this - address of open array argument is ot what it looks >>>> > >> like. To be sure you are getting address of various UNTRACED >>>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>>> > >>=20 >>>> > >> ADR(chars[0]) >>>> > >>=20 >>>> > >> and do not use: >>>> > >>=20 >>>> > >> LOOPHOLE(chars, ADDRESS) >>>> > >>=20 >>>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>>> > >> Right now II downgraded my code to use strstr(3), but this >>>> > >> argument passing still bugs me. >>>> > >>=20 >>>> > >> dd >>>> > >>=20 >>>> > >>=20 >>>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>>> > >>=20 >>>> > >> > What are the declarations of all the variables involved >>>> > >> in the call? >>>> > >> >=20 >>>> > >> > And what is the actual error? Is it a SIGBUS, >>>> > >> SIGSEGV? >>>> > >> >=20 >>>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>>> > >> >> I had some error before I LOOPHOLEd it. >>>> > >> >>=20 >>>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>>> > >> Benavides D. wrote: >>>> > >> >>=20 >>>> > >> >>> Hi all: >>>> > >> >>> if chars is ADDRESS type why are you >>>> > >> LOOPHOLE'ing it?=3D20 >>>> > >> >>> Thanks in advance >>>> > >> >>> =3D20 >>>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>> > >> >>>> > >> =3D >>>> > >> >> escribi=3DC3=3DB3: >>>> > >> >>> =3D20 >>>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>>> > >> lib >>>> > >> >>>> Para: "m3devel" >>>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>> > >> >>>> #1 0x00000035bd8172a0 in >>>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>>> > >> what=3D3D0x7
>>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>>> > >> start=3D3D0x0, >>>> > >> >>>> end=3D3D0x7fffffffdbb0) >>>> > >> >>>> at buffer.c:2441 >>>> > >> >>>> #2 0x0000000000404a0c in >>>> > >> Buffer__Search (t=3D3D>>> > >> >>>> reading variable>, pattern=3D3D>>> > >> reading >>>> > >> >>>> variable>, from=3D3D>>> > >> variable>,=3D20 >>>> > >> >>>> to=3D3D>>> > >> variable>) at >>>> > >> >>>> ../src/Buffer.m3:150 >>>> > >> >>>> =3D20 >>>> > >> >>>> Buffer.m3:150 >>>> > >> >>>> pos :=3D3D >>>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>>> > >> ADDRESS), len, >>>> > >> >>>> NIL, NIL); >>>> > >> >>>> =3D20 >>>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>>> > >> is Utypes.size_t and >>>> > >> >>>> it's value is 7. >>>> > >> >>>> =3D20 >>>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>>> > >> >>>> PROCEDURE search_range(buf: t; what: >>>> > >> char_star; len: size_t; >>>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>>> > >> >>>> =3D20 >>>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>>> > >> >>>> =3D20 >>>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>>> > >> >>>> last updated: 2010-07-21 >>>> > >> >>>> compiled: 2010-10-04 07:24:16 >>>> > >> >>>> configuration: /etc/cm3.cfg >>>> > >> >>>> host: AMD64_LINUX >>>> > >> >>>> target: AMD64_LINUX >>>> > >> >>>> =3D20 >>>> > >> >>>> =3D20 >>>> > >> >>>> Any ideas? TIA, >>>> > >> >>>> dd >>>> > >> >>>> =3D20 >>>> > >> >>>> =3D20 >>>> > >>=20 >>>> > >> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Mar 21 23:01:07 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 21 Mar 2012 18:01:07 -0400 Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <20120321220107.GA21387@topoi.pooq.com> On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. > I wonder if it would be easier I think to handle. > In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. > The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. > Thanks in advance While we're speculating, is there any chance SPIN would run on it? -- hendrik From dabenavidesd at yahoo.es Wed Mar 21 23:27:52 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 22:27:52 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <20120321220107.GA21387@topoi.pooq.com> Message-ID: <1332368872.19833.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I think we could, but I would center my focus on a Traditional Microkernel approach e.g Workplace OS (so, you could have instead of a Unix kernel level server on top of SPIN kernel) a personality in whatever language OS (Gnu/Linux, or better to say, M3/Linux) you want, in user mode (the larger part would be rewriting of lowest level of Mach, but ARX did that before it, abstraction of everything), even I know they ported AIX to Modula-3 at some point in the project. Thanks in advance --- El mi?, 21/3/12, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 21 de marzo, 2012 17:01 > On Wed, Mar 21, 2012 at 11:31:30AM > +0000, Daniel Alejandro Benavides D. wrote: > > Hi all: > > las t I thing I heard it changed from USB stick to > credit card sized, but I wonder if the USB stick is > available in any of Models. > > I wonder if it would be easier I think to handle. > > In any case, this good stuff to test a cross compiler, > I believe it is ARM32_LINUX, or so, but it would be > something akin Android phone-likes thing. > > The other question I was wondering if we can put on it > the ARX (because RIOS OS is adapting their OS as a third > party), they have told have they can emulate the thing for > now with a VM developed for their OS. > > Thanks in advance > > While we're speculating, is there any chance SPIN would run > on it? > > -- hendrik > From dragisha at m3w.org Thu Mar 22 12:08:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 22 Mar 2012 12:08:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: I'll try it soon, but I believe you are right. That is only place in whole libevent where I met with struct return value. Everything else I tried works good. dd On Mar 21, 2012, at 8:35 PM, Jay wrote: > Not good: don't return structs by value. Pass a pointer to where you want the result. > > - Jay (briefly/pocket-sized-computer-aka-phone) > > On Mar 21, 2012, at 5:25 AM, Dragi?a Duri? wrote: > >> <* EXTERNAL evbuffer_search *> >> PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; >> >> Tried both void_star and UNTRACED REF? >> >> On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: >> >>> Can you show your M3 interface declarations for these? >>> >>> Sent from my iPad >>> >>> On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: >>> >>>> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >>>> >>>> ===== >>>> struct evbuffer_ptr >>>> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >>>> { >>>> return evbuffer_search_range(buffer, what, len, start, NULL); >>>> } >>>> >>>> struct evbuffer_ptr >>>> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >>>> { >>>> >>>> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >>>> >>>>> That is a bit wierd. >>>>> Lots of things seem wierd at first..and wierd even at second, >>>>> but often there are reasons things are how they are, >>>>> and often there are barriers to change. >>>>> >>>>> >>>>> I would expect Ctypes.char = CHAR. >>>>> >>>>> >>>>> But I don't know why it isn't. >>>>> >>>>> >>>>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>>>> But it isn't. It is 8 bits and will never be larger. >>>>> >>>>> >>>>> You are really best not to interface directly to C that you didn't write >>>>> and the C that you write that you interface to, you are best restricting >>>>> to a subset of C. >>>>> >>>>> >>>>> And use m3-libs/m3core/src/unix for working examples. >>>>> >>>>> >>>>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>>>> I either didn't commit that or later removed it, leaving things as they >>>>> have been historically. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> > To: dabenavidesd at yahoo.es >>>>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>>>> > From: mika at async.caltech.edu >>>>> > CC: m3devel at elegosoft.com >>>>> > Subject: Re: [M3devel] Problem interfacing C lib >>>>> > >>>>> > char_star is, at least in my installation >>>>> > >>>>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>>>> > >>>>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>>>> > >>>>> > However >>>>> > >>>>> > ADR(chars[0]) >>>>> > >>>>> > ought to be more or less precisely of the type char_star >>>>> > >>>>> > ... so I doubt that is the problem. >>>>> > >>>>> > I'm curious about whether the assembly code for the call changes without >>>>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>>>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>>>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>>>> > >>>>> > Mika >>>>> > >>>>> > "Daniel Alejandro Benavides D." writes: >>>>> > >Hi all: >>>>> > >I think the unchecked error lays down to: >>>>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>>>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>>>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>>>> > >does not address a variable of type T." >>>>> > > >>>>> > >which could be reads conversely as: >>>>> > > >>>>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>>>> > >. It is a checked runtime error if the variable does not address a var= >>>>> > >iable of type .T=20 >>>>> > >=20 >>>>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>>>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>>>> > >ication. >>>>> > >So maybe you need to change your char_star >>>>> > > >>>>> > >Thanks in advance >>>>> > > >>>>> > > >>>>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>>>> > >=B3: >>>>> > > >>>>> > >> De: Dragi=C5=A1a Duri=C4=87 >>>>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>>>> > >> Para: "Mika Nystrom" >>>>> > >> CC: m3devel at elegosoft.com >>>>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>>>> > >> Errorr is SIGSEGV. >>>>> > >>=20 >>>>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>>>> > >> problem, I think. It looks like formal 'what' is not >>>>> > >> sent at all!? It's place is taken by next argument - INTEGER >>>>> > >> len (equal 0x7 in this example). >>>>> > >>=20 >>>>> > >> One common problem I meet often (as I bind C often :) is >>>>> > >> this - address of open array argument is ot what it looks >>>>> > >> like. To be sure you are getting address of various UNTRACED >>>>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>>>> > >>=20 >>>>> > >> ADR(chars[0]) >>>>> > >>=20 >>>>> > >> and do not use: >>>>> > >>=20 >>>>> > >> LOOPHOLE(chars, ADDRESS) >>>>> > >>=20 >>>>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>>>> > >> Right now II downgraded my code to use strstr(3), but this >>>>> > >> argument passing still bugs me. >>>>> > >>=20 >>>>> > >> dd >>>>> > >>=20 >>>>> > >>=20 >>>>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>>>> > >>=20 >>>>> > >> > What are the declarations of all the variables involved >>>>> > >> in the call? >>>>> > >> >=20 >>>>> > >> > And what is the actual error? Is it a SIGBUS, >>>>> > >> SIGSEGV? >>>>> > >> >=20 >>>>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>>>> > >> >> I had some error before I LOOPHOLEd it. >>>>> > >> >>=20 >>>>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>>>> > >> Benavides D. wrote: >>>>> > >> >>=20 >>>>> > >> >>> Hi all: >>>>> > >> >>> if chars is ADDRESS type why are you >>>>> > >> LOOPHOLE'ing it?=3D20 >>>>> > >> >>> Thanks in advance >>>>> > >> >>> =3D20 >>>>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>>> > >> >>>>> > >> =3D >>>>> > >> >> escribi=3DC3=3DB3: >>>>> > >> >>> =3D20 >>>>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>>>> > >> lib >>>>> > >> >>>> Para: "m3devel" >>>>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>>> > >> >>>> #1 0x00000035bd8172a0 in >>>>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>>>> > >> what=3D3D0x7
>>>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>>>> > >> start=3D3D0x0, >>>>> > >> >>>> end=3D3D0x7fffffffdbb0) >>>>> > >> >>>> at buffer.c:2441 >>>>> > >> >>>> #2 0x0000000000404a0c in >>>>> > >> Buffer__Search (t=3D3D>>>> > >> >>>> reading variable>, pattern=3D3D>>>> > >> reading >>>>> > >> >>>> variable>, from=3D3D>>>> > >> variable>,=3D20 >>>>> > >> >>>> to=3D3D>>>> > >> variable>) at >>>>> > >> >>>> ../src/Buffer.m3:150 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Buffer.m3:150 >>>>> > >> >>>> pos :=3D3D >>>>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>>>> > >> ADDRESS), len, >>>>> > >> >>>> NIL, NIL); >>>>> > >> >>>> =3D20 >>>>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>>>> > >> is Utypes.size_t and >>>>> > >> >>>> it's value is 7. >>>>> > >> >>>> =3D20 >>>>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>>>> > >> >>>> PROCEDURE search_range(buf: t; what: >>>>> > >> char_star; len: size_t; >>>>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>>>> > >> >>>> =3D20 >>>>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>>>> > >> >>>> last updated: 2010-07-21 >>>>> > >> >>>> compiled: 2010-10-04 07:24:16 >>>>> > >> >>>> configuration: /etc/cm3.cfg >>>>> > >> >>>> host: AMD64_LINUX >>>>> > >> >>>> target: AMD64_LINUX >>>>> > >> >>>> =3D20 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Any ideas? TIA, >>>>> > >> >>>> dd >>>>> > >> >>>> =3D20 >>>>> > >> >>>> =3D20 >>>>> > >>=20 >>>>> > >> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Mar 22 12:08:53 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 22 Mar 2012 12:08:53 +0100 Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <20120321220107.GA21387@topoi.pooq.com> References: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> <20120321220107.GA21387@topoi.pooq.com> Message-ID: <527A0212-B595-4D2D-9126-79BF9C762F57@m3w.org> Do we have all parts of SPIN? And do we have a right to modify it, etc etc? On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel Alejandro Benavides D. wrote: >> Hi all: >> las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. >> I wonder if it would be easier I think to handle. >> In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. >> The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. >> Thanks in advance > > While we're speculating, is there any chance SPIN would run on it? > > -- hendrik From dabenavidesd at yahoo.es Thu Mar 22 13:24:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 22 Mar 2012 12:24:25 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <527A0212-B595-4D2D-9126-79BF9C762F57@m3w.org> Message-ID: <1332419065.77273.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: I think they further developed source kernel, but several parts of it like the kernel drivers are left up to each one to setup (and as far as I know, they didn't want to open the ALPHA port, but the SPINE project would replace/update that port, I mean who cares an Alpha this days, unless you had something big there). However the Unix emulation server was more advanced in the Alpha port. However DEC UNIX server would matter only to anyone with that system, anyone? Thanks in advance --- El jue, 22/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: "Hendrik Boom" > CC: m3devel at elegosoft.com > Fecha: jueves, 22 de marzo, 2012 06:08 > Do we have all parts of SPIN? And do > we have a right to modify it, etc etc? > > On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > > > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel > Alejandro Benavides D. wrote: > >> Hi all: > >> las t I thing I heard it changed from USB stick to > credit card sized, but I wonder if the USB stick is > available in any of Models. > >> I wonder if it would be easier I think to handle. > >> In any case, this good stuff to test a cross > compiler, I believe it is ARM32_LINUX, or so, but it would > be something akin Android phone-likes thing. > >> The other question I was wondering if we can put on > it the ARX (because RIOS OS is adapting their OS as a third > party), they have told have they can emulate the thing for > now with a VM developed for their OS. > >> Thanks in advance > > > > While we're speculating, is there any chance SPIN would > run on it? > > > > -- hendrik > > From dabenavidesd at yahoo.es Fri Mar 23 16:50:36 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 23 Mar 2012 15:50:36 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <1332419065.77273.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <1332517836.93069.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: And as it happens, and other OS projects have died just because of that component in their OSes. My goal would be like this (based on some suppositions of course, but I'm almost certain of the following): - Modula-3 would allows to create a development environment capable of doing the hardest work, but will easy the self-construction of: - A driver manager system or sub-system, included in the micro-kernel, e.g Mach or ARX, or SPIN - A compiler self-trusted (currently SPIN just certifies based on type-checking but not any other static or at all procedure that I know) harvesting of trust, in which Baby Modula-3 self-constructing compiler would help to improve the most interesting parts of the compiler itself. - Development of specifications from documentation *available* of controllers. - Method implementations of them being written by hand, or with some sort of hackers help. - Self-checking of the above, and more static analysis techniques. - After we develop that, then it is time to implement the rest systematically, on architecture basic features grounds, which would allows us if possible to detect from existing drivers creation of new device drivers automatically. Possible target languages are logical ones, since most of drivers are written in assembly, then why not implemented in a logical manner (a.k.a NEC's LIME). Mika you have a Scheme interpreter, what is the status of that? Thanks in advance --- El jue, 22/3/12, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: "Hendrik Boom" , "Dragi?a Duri?" > CC: m3devel at elegosoft.com > Fecha: jueves, 22 de marzo, 2012 07:24 > Hi all: > I think they further developed source kernel, but several > parts of it like the kernel drivers are left up to each one > to setup (and as far as I know, they didn't want to open the > ALPHA port, but the SPINE project would replace/update that > port, I mean who cares an Alpha this days, unless you had > something big there). However the Unix emulation server was > more advanced in the Alpha port. However DEC UNIX server > would matter only to anyone with that system, anyone? > Thanks in advance > > --- El jue, 22/3/12, Dragi?a Duri? > escribi?: > > > De: Dragi?a Duri? > > Asunto: Re: [M3devel] cm3 on raspberry pi > > Para: "Hendrik Boom" > > CC: m3devel at elegosoft.com > > Fecha: jueves, 22 de marzo, 2012 06:08 > > Do we have all parts of SPIN? And do > > we have a right to modify it, etc etc? > > > > On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > > > > > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel > > Alejandro Benavides D. wrote: > > >> Hi all: > > >> las t I thing I heard it changed from USB > stick to > > credit card sized, but I wonder if the USB stick is > > available in any of Models. > > >> I wonder if it would be easier I think to > handle. > > >> In any case, this good stuff to test a cross > > compiler, I believe it is ARM32_LINUX, or so, but it > would > > be something akin Android phone-likes thing. > > >> The other question I was wondering if we can > put on > > it the ARX (because RIOS OS is adapting their OS as a > third > > party), they have told have they can emulate the thing > for > > now with a VM developed for their OS. > > >> Thanks in advance > > > > > > While we're speculating, is there any chance SPIN > would > > run on it? > > > > > > -- hendrik > > > > > From dragisha at m3w.org Sat Mar 24 12:27:06 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 24 Mar 2012 12:27:06 +0100 Subject: [M3devel] Status of ARM_DARWIN? Message-ID: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> Anybody using it? From dragisha at m3w.org Sat Mar 24 23:12:06 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 24 Mar 2012 23:12:06 +0100 Subject: [M3devel] quake c_source, gcc -I directive Message-ID: <8312AB2C-A725-4F9D-942B-9D7DE8A48E63@m3w.org> Anybody worked out an easy method resembling import_lib() to inform C compiler where to find include files in case it is not /usr/include? Like when I am using fink on a Mac, for example. TIA, dd From dragisha at m3w.org Sun Mar 25 00:41:31 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 00:41:31 +0100 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o My question is, can I dd -I/sw/include so if my source has #include It will be found in /sw/include/event2/event.h Of course, /usr/include, for system .h's, should work at same time. dd On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: > Hi all: > I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D > But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. > > > Thanks in advance > > --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: [M3devel] quake c_source, gcc -I directive >> Para: "m3devel" >> Fecha: s?bado, 24 de marzo, 2012 17:12 >> Anybody worked out an easy method >> resembling import_lib() to inform C compiler where to find >> include files in case it is not /usr/include? Like when I am >> using fink on a Mac, for example. >> >> TIA, >> dd >> >> From dabenavidesd at yahoo.es Sun Mar 25 00:37:49 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 24 Mar 2012 23:37:49 +0000 (GMT) Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <8312AB2C-A725-4F9D-942B-9D7DE8A48E63@m3w.org> Message-ID: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. Thanks in advance --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] quake c_source, gcc -I directive > Para: "m3devel" > Fecha: s?bado, 24 de marzo, 2012 17:12 > Anybody worked out an easy method > resembling import_lib() to inform C compiler where to find > include files in case it is not /usr/include? Like when I am > using fink on a Mac, for example. > > TIA, > dd > > From dabenavidesd at yahoo.es Sun Mar 25 01:07:44 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 25 Mar 2012 00:07:44 +0000 (GMT) Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> Message-ID: <1332634064.98273.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Maybe you need to create a package for that thing there /sw/include/event and create a symbolic link to it named src and compile and ship it. Then you would import the package as everything. Wouldn't it? Thanks in advance --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] quake c_source, gcc -I directive > Para: "Daniel Alejandro Benavides D." > CC: "m3devel" > Fecha: s?bado, 24 de marzo, 2012 18:41 > c_source("file") will compile file.c > in same directory as m3makefile with that line is. And put > object in ../$TARGET/file.o > > My question is, can I dd -I/sw/include so if my source has > > #include > > It will be found in /sw/include/event2/event.h > > Of course, /usr/include, for system .h's, should work at > same time. > > dd > > > On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > I thought the c_source file had to be named in the same > way your modula-3 sources (src), but for any other purposes > like finding utilities inside your src tree src/D > > But if that's not the implementation you need but to > link against I had to actually call the var outside the > Modula-3 environment to override it in Modula-3 system > linker. > > > > > > Thanks in advance > > > > --- El s?b, 24/3/12, Dragi?a Duri? > escribi?: > > > >> De: Dragi?a Duri? > >> Asunto: [M3devel] quake c_source, gcc -I directive > >> Para: "m3devel" > >> Fecha: s?bado, 24 de marzo, 2012 17:12 > >> Anybody worked out an easy method > >> resembling import_lib() to inform C compiler where > to find > >> include files in case it is not /usr/include? Like > when I am > >> using fink on a Mac, for example. > >> > >> TIA, > >> dd > >> > >> > > From darko at darko.org Sun Mar 25 06:55:17 2012 From: darko at darko.org (Darko) Date: Sat, 24 Mar 2012 21:55:17 -0700 Subject: [M3devel] Status of ARM_DARWIN? In-Reply-To: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> References: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> Message-ID: <4925F43C-C418-4507-8038-C63408495220@darko.org> I don't think it works right now. I think native ARM_DARWIN and ARM_LINUX implementations would be a blessing given the proliferation of ARM devices, though. On 24/03/2012, at 4:27 AM, Dragi?a Duri? wrote: > Anybody using it? From dragisha at m3w.org Sun Mar 25 09:46:13 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 09:46:13 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> Message-ID: <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org> Read through Darwin.common,Unix.common? No mention. SYSTEM_LIBS is for -L dd On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: > Can you not augment the standard system .h include paths as per the m3.cfg? > > On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: > >> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o >> >> My question is, can I dd -I/sw/include so if my source has >> >> #include >> >> It will be found in /sw/include/event2/event.h >> >> Of course, /usr/include, for system .h's, should work at same time. >> >> dd >> >> >> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D >>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. >>> >>> >>> Thanks in advance >>> >>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: >>> >>>> De: Dragi?a Duri? >>>> Asunto: [M3devel] quake c_source, gcc -I directive >>>> Para: "m3devel" >>>> Fecha: s?bado, 24 de marzo, 2012 17:12 >>>> Anybody worked out an easy method >>>> resembling import_lib() to inform C compiler where to find >>>> include files in case it is not /usr/include? Like when I am >>>> using fink on a Mac, for example. >>>> >>>> TIA, >>>> dd >>>> >>>> >> > From dragisha at m3w.org Sun Mar 25 21:33:18 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 21:33:18 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org> Message-ID: I tried obvious thing :) "/Users/dragisha/m3/libevent/src/m3makefile", line 9: quake runtime error: wrong number of parameters passed to procedure c_source (expected 1, received 2) On Mar 25, 2012, at 3:49 PM, Antony Hosking wrote: > I am sure there is a way to do what you want with a simple one-liner in the m3makefile. > Anyone remember? > > On Mar 25, 2012, at 3:46 AM, Dragi?a Duri? wrote: > >> Read through Darwin.common,Unix.common? No mention. >> >> SYSTEM_LIBS is for -L >> >> dd >> >> On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: >> >>> Can you not augment the standard system .h include paths as per the m3.cfg? >>> >>> On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: >>> >>>> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o >>>> >>>> My question is, can I dd -I/sw/include so if my source has >>>> >>>> #include >>>> >>>> It will be found in /sw/include/event2/event.h >>>> >>>> Of course, /usr/include, for system .h's, should work at same time. >>>> >>>> dd >>>> >>>> >>>> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: >>>> >>>>> Hi all: >>>>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D >>>>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. >>>>> >>>>> >>>>> Thanks in advance >>>>> >>>>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: >>>>> >>>>>> De: Dragi?a Duri? >>>>>> Asunto: [M3devel] quake c_source, gcc -I directive >>>>>> Para: "m3devel" >>>>>> Fecha: s?bado, 24 de marzo, 2012 17:12 >>>>>> Anybody worked out an easy method >>>>>> resembling import_lib() to inform C compiler where to find >>>>>> include files in case it is not /usr/include? Like when I am >>>>>> using fink on a Mac, for example. >>>>>> >>>>>> TIA, >>>>>> dd >>>>>> >>>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Mar 26 04:40:15 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Mar 2012 02:40:15 +0000 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com>, <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org>, <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com>, <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org>, , Message-ID: We should support something like CFLAGS = CFLAGS & " -I/whatever" but we don't currently. ? SYSTEM_CC = SYSTEM_CC & " -I/whatever"almost works, but I don't believe generally does. - in the past, because SYSTEM_CC was readonly - currently because SYSTEM_CC is in some systems dynamically determined if/when any C code needs to be via configure_c_compiler (see cm3cfg.common) I don't know if Quake works this, way, but it'd be nice to be able to this: if defined(configure_c_compiler) previous_configure_c_compiler = configure_c_compiler else proc previous_configure_c_compiler() is end endproc configure_c_compiler() is previous_configure_c_compiler() SYSTEM_CC = SYSTEM_CC & " -I/whatever end more generally though, this should be somehow abstracted per-platform like SYSTEM_LIBS? Granted, it is kind of the same for all C compilers, the -I switch. The idea of a mult-dimensional abstraction per-library/include per-target per-host per-compiler (cc vs. gcc) is kind of annoying, esp. given that -I is pretty universial. I feel like I'm missing something though. We did have something like "CFLAGS". But I don't see it currently..I'm not looking in a smart way..maybe more later....maybe... - Jay > From: dragisha at m3w.org > Date: Sun, 25 Mar 2012 21:33:18 +0200 > To: antony.hosking at gmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quake c_source, gcc -I directive > > I tried obvious thing :) > > "/Users/dragisha/m3/libevent/src/m3makefile", line 9: quake runtime error: wrong number of parameters passed to procedure c_source (expected 1, received 2) > > > On Mar 25, 2012, at 3:49 PM, Antony Hosking wrote: > > > I am sure there is a way to do what you want with a simple one-liner in the m3makefile. > > Anyone remember? > > > > On Mar 25, 2012, at 3:46 AM, Dragi?a Duri? wrote: > > > >> Read through Darwin.common,Unix.common. No mention. > >> > >> SYSTEM_LIBS is for -L > >> > >> dd > >> > >> On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: > >> > >>> Can you not augment the standard system .h include paths as per the m3.cfg? > >>> > >>> On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: > >>> > >>>> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o > >>>> > >>>> My question is, can I dd -I/sw/include so if my source has > >>>> > >>>> #include > >>>> > >>>> It will be found in /sw/include/event2/event.h > >>>> > >>>> Of course, /usr/include, for system .h's, should work at same time. > >>>> > >>>> dd > >>>> > >>>> > >>>> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: > >>>> > >>>>> Hi all: > >>>>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D > >>>>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. > >>>>> > >>>>> > >>>>> Thanks in advance > >>>>> > >>>>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > >>>>> > >>>>>> De: Dragi?a Duri? > >>>>>> Asunto: [M3devel] quake c_source, gcc -I directive > >>>>>> Para: "m3devel" > >>>>>> Fecha: s?bado, 24 de marzo, 2012 17:12 > >>>>>> Anybody worked out an easy method > >>>>>> resembling import_lib() to inform C compiler where to find > >>>>>> include files in case it is not /usr/include? Like when I am > >>>>>> using fink on a Mac, for example. > >>>>>> > >>>>>> TIA, > >>>>>> dd > >>>>>> > >>>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Mar 26 09:04:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 26 Mar 2012 09:04:29 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com>, <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org>, <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com>, <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org>, , Message-ID: <2DC7D00F-79E4-4FFD-BCF5-71139A9D563D@m3w.org> Works on AMD64_DARWIN, and that is what I neeed. Thank you! I think we need third argument to import_lib(). dd On Mar 26, 2012, at 4:40 AM, Jay K wrote: > We should support something like > CFLAGS = CFLAGS & " -I/whatever" > > > but we don't currently. ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 16:06:00 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 16:06:00 +0100 Subject: [M3devel] LONGINT Message-ID: It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 16:50:14 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 16:50:14 +0100 Subject: [M3devel] LONGINT In-Reply-To: <04BF2F51-1AA6-44B6-81A2-A66E5BE4494B@gmail.com> References: <04BF2F51-1AA6-44B6-81A2-A66E5BE4494B@gmail.com> Message-ID: Yes, that compiles, but looks a bit perverse since one intuitively is induced to think that the VAL source should fit the VAL destination because it is a "legal" LOOPHOLE and should be submitted to the same restrictions as the latter. From: Antony Hosking Sent: Saturday, March 10, 2012 4:32 PM To: Dirk Muysers Cc: m3devel at elegosoft.com Subject: Re: [M3devel] LONGINT Have you tried ORD(VAL(x, INTEGER)) where x is a LONGINT? I?m surprised about the second problem. Perhaps it is not yet fixed in that release. On Mar 10, 2012, at 10:06 AM, Dirk Muysers wrote: It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Mar 10 17:07:16 2012 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sat, 10 Mar 2012 17:07:16 +0100 Subject: [M3devel] ORD/VAL Message-ID: Reading once more through chapter 2.6.13 of the latest language reference, I come to the conclusion that we should have left ORD/VAL to the enumerations where they originally belonged to and have added an explicit LONG/SHORT builtin as the Oberon folks did. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Mar 10 22:22:35 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 10 Mar 2012 21:22:35 +0000 (GMT) Subject: [M3devel] LONGINT In-Reply-To: Message-ID: <1331414555.7112.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: I was reading a Embeddable Module modification to Oberon: http://www1.chapman.edu/~radenski/research/papers/module.pdf ?based on the fact of the Modules being a central concept, so making Module types, etc, but thinking in it more what about Integer.T like Word.T DEC-SRC style Module naming scheme, etc? And furthermore, what about QuadWord, etc? Let me know what do you think Thanks in advance --- El s?b, 10/3/12, Dirk Muysers escribi?: De: Dirk Muysers Asunto: [M3devel] LONGINT Para: m3devel at elegosoft.com Fecha: s?bado, 10 de marzo, 2012 10:06 It is my understanding that ORD(x), where x is a LONGINT should return x as an INTEGER, provided?the (hidden) range check succeeds. It actually fails to compile (cm3 5.8.6 on Win32) with "Incompatible types (n)". And, also, one can't specify a LONGINT literal greater than LAST(INTEGER). ("invalid longint literal"). ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Mar 10 23:21:41 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 10 Mar 2012 23:21:41 +0100 Subject: [M3devel] ORD/VAL In-Reply-To: References: Message-ID: Nobody is forced to use ORD/VAL "outside" of enumerations. I CHAR enumerated type? WIDECHAR? On Mar 10, 2012, at 5:07 PM, Dirk Muysers wrote: > Reading once more through chapter 2.6.13 of the latest language > reference, I come to the conclusion that we should have left ORD/VAL > to the enumerations where they originally belonged to and have > added an explicit LONG/SHORT builtin as the Oberon folks did. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 12 02:46:28 2012 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Mar 2012 18:46:28 -0700 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <7696194F-EF9E-4348-BCF4-E5216B826CCF@gmail.com> References: <1329596426.45026.YahooMailClassic@web29706.mail.ird.yahoo.com> <7696194F-EF9E-4348-BCF4-E5216B826CCF@gmail.com> Message-ID: Anyone here want some 12" Macintosh PowerPC laptops? I have at least 3. They haven't been used in months/years. - Jay >> From dabenavidesd at yahoo.es Mon Mar 12 03:37:33 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 12 Mar 2012 02:37:33 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: Message-ID: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi: what kind of laptop (mini) or sort of? What OS is it? Any special reason(s) for taking three of them? Thanks in advance. --- El dom, 11/3/12, Jay escribi?: > De: Jay > Asunto: [M3devel] 3 Macintosh PowerPC laptops? > Para: "m3devel at elegosoft.com" > Fecha: domingo, 11 de marzo, 2012 20:46 > Anyone here want some 12" Macintosh > PowerPC laptops? I have at least 3. They haven't been used > in months/years. > > - Jay > >> > From jay.krell at cornell.edu Mon Mar 12 04:37:44 2012 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Mar 2012 20:37:44 -0700 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <1331519853.70432.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com> 12" 3: that's how many I have found so cleaning. They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD and one can run MacOS 9. - Jay (phone) On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." wrote: > Hi: > what kind of laptop (mini) or sort of? > What OS is it? > Any special reason(s) for taking three of them? > Thanks in advance. > > --- El dom, 11/3/12, Jay escribi?: > >> De: Jay >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? >> Para: "m3devel at elegosoft.com" >> Fecha: domingo, 11 de marzo, 2012 20:46 >> Anyone here want some 12" Macintosh >> PowerPC laptops? I have at least 3. They haven't been used >> in months/years. >> >> - Jay >>>> >> From dabenavidesd at yahoo.es Mon Mar 12 20:44:04 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 12 Mar 2012 19:44:04 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com> Message-ID: <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi: Is it 64 bit laptop? How much does it weight? Is it light-weight? Thanks in advance --- El dom, 11/3/12, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > Para: "Daniel Alejandro Benavides D." > CC: "m3devel at elegosoft.com" , "Jay" > Fecha: domingo, 11 de marzo, 2012 22:37 > 12" > 3: that's how many I have found so cleaning. > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > and one can run MacOS 9. > > - Jay (phone) > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > wrote: > > > Hi: > > what kind of laptop (mini) or sort of? > > What OS is it? > > Any special reason(s) for taking three of them? > > Thanks in advance. > > > > --- El dom, 11/3/12, Jay > escribi?: > > > >> De: Jay > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > >> Para: "m3devel at elegosoft.com" > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > >> Anyone here want some 12" Macintosh > >> PowerPC laptops? I have at least 3. They haven't > been used > >> in months/years. > >> > >> - Jay > >>>> > >> > From jay.krell at cornell.edu Mon Mar 12 21:28:54 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Mar 2012 20:28:54 +0000 Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> References: <8CCCBACC-42ED-43E6-8015-BE03E4D028AB@gmail.com>, <1331581444.21557.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: I've never heard of a 64bit PowerPC laptop. - Jay > Date: Mon, 12 Mar 2012 19:44:04 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] 3 Macintosh PowerPC laptops? > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi: > Is it 64 bit laptop? > How much does it weight? Is it light-weight? > > Thanks in advance > > --- El dom, 11/3/12, Jay escribi?: > > > De: Jay > > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > > Para: "Daniel Alejandro Benavides D." > > CC: "m3devel at elegosoft.com" , "Jay" > > Fecha: domingo, 11 de marzo, 2012 22:37 > > 12" > > 3: that's how many I have found so cleaning. > > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > > and one can run MacOS 9. > > > > - Jay (phone) > > > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > > > wrote: > > > > > Hi: > > > what kind of laptop (mini) or sort of? > > > What OS is it? > > > Any special reason(s) for taking three of them? > > > Thanks in advance. > > > > > > --- El dom, 11/3/12, Jay > > escribi?: > > > > > >> De: Jay > > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > > >> Para: "m3devel at elegosoft.com" > > > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > > >> Anyone here want some 12" Macintosh > > >> PowerPC laptops? I have at least 3. They haven't > > been used > > >> in months/years. > > >> > > >> - Jay > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 13 15:57:33 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 13 Mar 2012 14:57:33 +0000 (GMT) Subject: [M3devel] 3 Macintosh PowerPC laptops? In-Reply-To: Message-ID: <1331650653.43835.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi: maybe in my mind or something like that is introduced by the name of Ultra-Book, or something affine. Saw some announcement on Modular computer nodes for military-aerospeace applications. Some tough machines. I have to try to see one built itself around that idea, but it's not the eighties and we're not quite there! Specially if Semiconductor fabrics are not sharing anything. But I like the idea of being ultra-thin, how thick it is as is? Thanks in advance --- El lun, 12/3/12, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] 3 Macintosh PowerPC laptops? Para: dabenavidesd at yahoo.es CC: "m3devel" Fecha: lunes, 12 de marzo, 2012 15:28 I've never heard of a 64bit PowerPC laptop. ? ?- Jay ? > Date: Mon, 12 Mar 2012 19:44:04 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] 3 Macintosh PowerPC laptops? > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi: > Is it 64 bit laptop? > How much does it weight? Is it light-weight? > > Thanks in advance > > --- El dom, 11/3/12, Jay escribi?: > > > De: Jay > > Asunto: Re: [M3devel] 3 Macintosh PowerPC laptops? > > Para: "Daniel Alejandro Benavides D." > > CC: "m3devel at elegosoft.com" , "Jay" > > Fecha: domingo, 11 de marzo, 2012 22:37 > > 12" > > 3: that's how many I have found so cleaning. > > They can run MacOSX Linux probably NetBSD OpenBSD FreeBSD > > and one can run MacOS 9. > > > > - Jay (phone) > > > > On Mar 11, 2012, at 7:37 PM, "Daniel Alejandro Benavides D." > > > > wrote: > > > > > Hi: > > > what kind of laptop (mini) or sort of? > > > What OS is it? > > > Any special reason(s) for taking three of them? > > > Thanks in advance. > > > > > > --- El dom, 11/3/12, Jay > > escribi?: > > > > > >> De: Jay > > >> Asunto: [M3devel] 3 Macintosh PowerPC laptops? > > >> Para: "m3devel at elegosoft.com" > > > > >> Fecha: domingo, 11 de marzo, 2012 20:46 > > >> Anyone here want some 12" Macintosh > > >> PowerPC laptops? I have at least 3. They haven't > > been used > > >> in months/years. > > >> > > >> - Jay > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Mar 19 18:13:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 18:13:29 +0100 Subject: [M3devel] Problem interfacing C lib Message-ID: #1 0x00000035bd8172a0 in evbuffer_search_range (buffer=0x694090, what=0x7
, len=0, start=0x0, end=0x7fffffffdbb0) at buffer.c:2441 #2 0x0000000000404a0c in Buffer__Search (t=, pattern=, from=, to=) at ../src/Buffer.m3:150 Buffer.m3:150 pos := evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, NIL, NIL); t.b is a pointer, so is chars? len is Utypes.size_t and it's value is 7. <* EXTERNAL evbuffer_search_range *> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: UNTRACED REF ptr): ptr; t is an ADDRESS, and so on? Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2010-10-04 07:24:16 configuration: /etc/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX Any ideas? TIA, dd From dabenavidesd at yahoo.es Mon Mar 19 19:27:15 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 19 Mar 2012 18:27:15 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: Message-ID: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: if chars is ADDRESS type why are you LOOPHOLE'ing it? Thanks in advance --- El lun, 19/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] Problem interfacing C lib > Para: "m3devel" > Fecha: lunes, 19 de marzo, 2012 12:13 > #1 0x00000035bd8172a0 in > evbuffer_search_range (buffer=0x694090, what=0x7
0x7 out of bounds>, len=0, start=0x0, > end=0x7fffffffdbb0) > at buffer.c:2441 > #2 0x0000000000404a0c in Buffer__Search (t= reading variable>, pattern= variable>, from=, > to=) at > ../src/Buffer.m3:150 > > Buffer.m3:150 > pos := > evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, > NIL, NIL); > > t.b is a pointer, so is chars? len is Utypes.size_t and > it's value is 7. > > <* EXTERNAL evbuffer_search_range *> > PROCEDURE search_range(buf: t; what: char_star; len: size_t; > start, end: UNTRACED REF ptr): ptr; > > t is an ADDRESS, and so on? > > Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-10-04 07:24:16 > configuration: /etc/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > > Any ideas? TIA, > dd > > From dragisha at m3w.org Mon Mar 19 23:44:20 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 23:44:20 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <520FB9AC-1CF9-414B-89CE-3A1FED4968B4@gmail.com> References: <520FB9AC-1CF9-414B-89CE-3A1FED4968B4@gmail.com> Message-ID: Tried that earlier? One of my first guesses. Same thing happens. On Mar 19, 2012, at 6:47 PM, Antony Hosking wrote: > > On Mar 19, 2012, at 1:13 PM, Dragi?a Duri? wrote: > >> #1 0x00000035bd8172a0 in evbuffer_search_range (buffer=0x694090, what=0x7
, len=0, start=0x0, end=0x7fffffffdbb0) >> at buffer.c:2441 >> #2 0x0000000000404a0c in Buffer__Search (t=, pattern=, from=, >> to=) at ../src/Buffer.m3:150 >> >> Buffer.m3:150 >> pos := evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, NIL, NIL); >> >> t.b is a pointer, so is chars? len is Utypes.size_t and it's value is 7. >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: UNTRACED REF ptr): ptr; > > I?m betting start and end should be ADDRESS, not UNTRACED REF. I am sure that they do not refer to an allocated ptr, but rather to some address within buf or char_star. Is chars an array? In which case, perhaps ADR(chars[0])? > >> >> t is an ADDRESS, and so on? >> >> Critical Mass Modula-3 version d5.9.0 >> last updated: 2010-07-21 >> compiled: 2010-10-04 07:24:16 >> configuration: /etc/cm3.cfg >> host: AMD64_LINUX >> target: AMD64_LINUX >> >> >> Any ideas? TIA, >> dd >> > From dragisha at m3w.org Mon Mar 19 23:45:02 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 19 Mar 2012 23:45:02 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> I had some error before I LOOPHOLEd it. On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > if chars is ADDRESS type why are you LOOPHOLE'ing it? > Thanks in advance > > --- El lun, 19/3/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: [M3devel] Problem interfacing C lib >> Para: "m3devel" >> Fecha: lunes, 19 de marzo, 2012 12:13 >> #1 0x00000035bd8172a0 in >> evbuffer_search_range (buffer=0x694090, what=0x7
> 0x7 out of bounds>, len=0, start=0x0, >> end=0x7fffffffdbb0) >> at buffer.c:2441 >> #2 0x0000000000404a0c in Buffer__Search (t=> reading variable>, pattern=> variable>, from=, >> to=) at >> ../src/Buffer.m3:150 >> >> Buffer.m3:150 >> pos := >> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >> NIL, NIL); >> >> t.b is a pointer, so is chars? len is Utypes.size_t and >> it's value is 7. >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >> start, end: UNTRACED REF ptr): ptr; >> >> t is an ADDRESS, and so on? >> >> Critical Mass Modula-3 version d5.9.0 >> last updated: 2010-07-21 >> compiled: 2010-10-04 07:24:16 >> configuration: /etc/cm3.cfg >> host: AMD64_LINUX >> target: AMD64_LINUX >> >> >> Any ideas? TIA, >> dd >> >> From mika at async.caltech.edu Tue Mar 20 01:26:46 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 19 Mar 2012 17:26:46 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> Message-ID: <20120320002646.AF1FD1A207C@async.async.caltech.edu> What are the declarations of all the variables involved in the call? And what is the actual error? Is it a SIGBUS, SIGSEGV? =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >I had some error before I LOOPHOLEd it. > >On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: > >> Hi all: >> if chars is ADDRESS type why are you LOOPHOLE'ing it?=20 >> Thanks in advance >>=20 >> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 = >escribi=C3=B3: >>=20 >>> De: Dragi=C5=A1a Duri=C4=87 >>> Asunto: [M3devel] Problem interfacing C lib >>> Para: "m3devel" >>> Fecha: lunes, 19 de marzo, 2012 12:13 >>> #1 0x00000035bd8172a0 in >>> evbuffer_search_range (buffer=3D0x694090, what=3D0x7
>> 0x7 out of bounds>, len=3D0, start=3D0x0, >>> end=3D0x7fffffffdbb0) >>> at buffer.c:2441 >>> #2 0x0000000000404a0c in Buffer__Search (t=3D>> reading variable>, pattern=3D>> variable>, from=3D,=20 >>> to=3D) at >>> ../src/Buffer.m3:150 >>>=20 >>> Buffer.m3:150 >>> pos :=3D >>> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >>> NIL, NIL); >>>=20 >>> t.b is a pointer, so is chars=E2=80=A6 len is Utypes.size_t and >>> it's value is 7. >>>=20 >>> <* EXTERNAL evbuffer_search_range *> >>> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >>> start, end: UNTRACED REF ptr): ptr; >>>=20 >>> t is an ADDRESS, and so on=E2=80=A6 >>>=20 >>> Critical Mass Modula-3 version d5.9.0 >>> last updated: 2010-07-21 >>> compiled: 2010-10-04 07:24:16 >>> configuration: /etc/cm3.cfg >>> host: AMD64_LINUX >>> target: AMD64_LINUX >>>=20 >>>=20 >>> Any ideas? TIA, >>> dd >>>=20 >>>=20 From dragisha at m3w.org Tue Mar 20 07:04:58 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Mar 2012 07:04:58 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320002646.AF1FD1A207C@async.async.caltech.edu> References: <1332181635.34500.YahooMailClassic@web29705.mail.ird.yahoo.com> <09FD8480-680A-4A15-98D7-03F84F30CB5A@m3w.org> <20120320002646.AF1FD1A207C@async.async.caltech.edu> Message-ID: Errorr is SIGSEGV. chars is UNTRACED REF ARRAY OF CHAR but it is lesser problem, I think. It looks like formal 'what' is not sent at all!? It's place is taken by next argument - INTEGER len (equal 0x7 in this example). One common problem I meet often (as I bind C often :) is this - address of open array argument is ot what it looks like. To be sure you are getting address of various UNTRACED REF..ARRAY.. and open array procedure arguments - use ADR(chars[0]) and do not use: LOOPHOLE(chars, ADDRESS) Of course, I tried ADR(chars[0]) :) - Same thing happened. Right now II downgraded my code to use strstr(3), but this argument passing still bugs me. dd On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > What are the declarations of all the variables involved in the call? > > And what is the actual error? Is it a SIGBUS, SIGSEGV? > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >> I had some error before I LOOPHOLEd it. >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> if chars is ADDRESS type why are you LOOPHOLE'ing it?=20 >>> Thanks in advance >>> =20 >>> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 = >> escribi=C3=B3: >>> =20 >>>> De: Dragi=C5=A1a Duri=C4=87 >>>> Asunto: [M3devel] Problem interfacing C lib >>>> Para: "m3devel" >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>> #1 0x00000035bd8172a0 in >>>> evbuffer_search_range (buffer=3D0x694090, what=3D0x7
>>> 0x7 out of bounds>, len=3D0, start=3D0x0, >>>> end=3D0x7fffffffdbb0) >>>> at buffer.c:2441 >>>> #2 0x0000000000404a0c in Buffer__Search (t=3D>>> reading variable>, pattern=3D>>> variable>, from=3D,=20 >>>> to=3D) at >>>> ../src/Buffer.m3:150 >>>> =20 >>>> Buffer.m3:150 >>>> pos :=3D >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), len, >>>> NIL, NIL); >>>> =20 >>>> t.b is a pointer, so is chars=E2=80=A6 len is Utypes.size_t and >>>> it's value is 7. >>>> =20 >>>> <* EXTERNAL evbuffer_search_range *> >>>> PROCEDURE search_range(buf: t; what: char_star; len: size_t; >>>> start, end: UNTRACED REF ptr): ptr; >>>> =20 >>>> t is an ADDRESS, and so on=E2=80=A6 >>>> =20 >>>> Critical Mass Modula-3 version d5.9.0 >>>> last updated: 2010-07-21 >>>> compiled: 2010-10-04 07:24:16 >>>> configuration: /etc/cm3.cfg >>>> host: AMD64_LINUX >>>> target: AMD64_LINUX >>>> =20 >>>> =20 >>>> Any ideas? TIA, >>>> dd >>>> =20 >>>> =20 From mika at async.caltech.edu Tue Mar 20 07:41:35 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 19 Mar 2012 23:41:35 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: Message-ID: <20120320064135.A5A601A207C@async.async.caltech.edu> Hmm... it looks like it's skipping the pushing of what on the stack, you mean? Very odd, I'd say...! Did you look at the assembly? =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >#1 0x00000035bd8172a0 in evbuffer_search_range (buffer=3D0x694090, = >what=3D0x7
, len=3D0, start=3D0x0, = >end=3D0x7fffffffdbb0) > at buffer.c:2441 >#2 0x0000000000404a0c in Buffer__Search (t=3D, = >pattern=3D, from=3D,=20 > to=3D) at ../src/Buffer.m3:150 > >Buffer.m3:150 > pos :=3D evbuffer.search_range(t.b, LOOPHOLE(chars, ADDRESS), = >len, NIL, NIL); > >t.b is a pointer, so is chars=85 len is Utypes.size_t and it's value is = >7. > ><* EXTERNAL evbuffer_search_range *> >PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: = >UNTRACED REF ptr): ptr; > >t is an ADDRESS, and so on=85 > >Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-10-04 07:24:16 > configuration: /etc/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > >Any ideas? TIA, >dd From dragisha at m3w.org Tue Mar 20 08:00:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Mar 2012 08:00:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320064135.A5A601A207C@async.async.caltech.edu> References: <20120320064135.A5A601A207C@async.async.caltech.edu> Message-ID: <378E40B0-8785-481F-A327-1C66D2B219CA@m3w.org> Yes, it is. No 'what' pushed at all, and some garbage got place in formal list, from the end.. In this case "garbage" is pointer to return value (of some RECORD type). Or it's base pointer (BP)? Can be - my assembly days were some time ago :). I did not analyze this deeper, not yet. I am in the middle of a project (aren't we always:) so I just made workaround here. dd On Mar 20, 2012, at 7:41 AM, Mika Nystrom wrote: > Hmm... it looks like it's skipping the pushing of what on the stack, you mean? > Very odd, I'd say...! > > Did you look at the assembly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 20 22:31:34 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Mar 2012 21:31:34 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: Message-ID: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: I think the unchecked error lays down to: Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): it's allowed to have " ... a value of type ADDRESS to be assigned to a variable of type UNTRACED REF T. It is an unchecked runtime error if the value does not address a variable of type T." which could be reads conversely as: a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS. It is a checked runtime error if the variable does not address a variable of type .T And because because char_star is a subrange [-128 .. 127] OF INTEGER (and not ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specification. So maybe you need to change your char_star Thanks in advance --- El mar, 20/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 01:04 > Errorr is SIGSEGV. > > chars is UNTRACED REF ARRAY OF CHAR but it is lesser > problem, I think. It looks like formal 'what' is not > sent at all!? It's place is taken by next argument - INTEGER > len (equal 0x7 in this example). > > One common problem I meet often (as I bind C often :) is > this - address of open array argument is ot what it looks > like. To be sure you are getting address of various UNTRACED > REF..ARRAY.. and open array procedure arguments - use > > ADR(chars[0]) > > and do not use: > > LOOPHOLE(chars, ADDRESS) > > Of course, I tried ADR(chars[0]) :) - Same thing happened. > Right now II downgraded my code to use strstr(3), but this > argument passing still bugs me. > > dd > > > On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > > > What are the declarations of all the variables involved > in the call? > > > > And what is the actual error? Is it a SIGBUS, > SIGSEGV? > > > > =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >> I had some error before I LOOPHOLEd it. > >> > >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > Benavides D. wrote: > >> > >>> Hi all: > >>> if chars is ADDRESS type why are you > LOOPHOLE'ing it?=20 > >>> Thanks in advance > >>> =20 > >>> --- El lun, 19/3/12, Dragi=C5=A1a Duri=C4=87 > > = > >> escribi=C3=B3: > >>> =20 > >>>> De: Dragi=C5=A1a Duri=C4=87 > >>>> Asunto: [M3devel] Problem interfacing C > lib > >>>> Para: "m3devel" > >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > >>>> #1 0x00000035bd8172a0 in > >>>> evbuffer_search_range (buffer=3D0x694090, > what=3D0x7
>>>> 0x7 out of bounds>, len=3D0, > start=3D0x0, > >>>> end=3D0x7fffffffdbb0) > >>>> at buffer.c:2441 > >>>> #2 0x0000000000404a0c in > Buffer__Search (t=3D >>>> reading variable>, pattern=3D reading > >>>> variable>, from=3D variable>,=20 > >>>> to=3D variable>) at > >>>> ../src/Buffer.m3:150 > >>>> =20 > >>>> Buffer.m3:150 > >>>> pos :=3D > >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > ADDRESS), len, > >>>> NIL, NIL); > >>>> =20 > >>>> t.b is a pointer, so is chars=E2=80=A6 len > is Utypes.size_t and > >>>> it's value is 7. > >>>> =20 > >>>> <* EXTERNAL evbuffer_search_range *> > >>>> PROCEDURE search_range(buf: t; what: > char_star; len: size_t; > >>>> start, end: UNTRACED REF ptr): ptr; > >>>> =20 > >>>> t is an ADDRESS, and so on=E2=80=A6 > >>>> =20 > >>>> Critical Mass Modula-3 version d5.9.0 > >>>> last updated: 2010-07-21 > >>>> compiled: 2010-10-04 07:24:16 > >>>> configuration: /etc/cm3.cfg > >>>> host: AMD64_LINUX > >>>> target: AMD64_LINUX > >>>> =20 > >>>> =20 > >>>> Any ideas? TIA, > >>>> dd > >>>> =20 > >>>> =20 > > From mika at async.caltech.edu Tue Mar 20 23:06:59 2012 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 20 Mar 2012 15:06:59 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> Message-ID: <20120320220659.9136A1A207C@async.async.caltech.edu> char_star is, at least in my installation UNTRACED REF [-16_7f-1 .. 16_7f] But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR However ADR(chars[0]) ought to be more or less precisely of the type char_star ... so I doubt that is the problem. I'm curious about whether the assembly code for the call changes without the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where is chars passed, in pure Modula-3 code? I don't know enough about the standard ABI of amd64 to know what the code should look like I'm afraid. Mika "Daniel Alejandro Benavides D." writes: >Hi all: >I think the unchecked error lays down to: >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >does not address a variable of type T." > >which could be reads conversely as: > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >. It is a checked runtime error if the variable does not address a var= >iable of type .T=20 >=20 >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >ication. >So maybe you need to change your char_star > >Thanks in advance > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >=B3: > >> De: Dragi=C5=A1a Duri=C4=87 >> Asunto: Re: [M3devel] Problem interfacing C lib >> Para: "Mika Nystrom" >> CC: m3devel at elegosoft.com >> Fecha: martes, 20 de marzo, 2012 01:04 >> Errorr is SIGSEGV. >>=20 >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >> problem, I think. It looks like formal 'what' is not >> sent at all!? It's place is taken by next argument - INTEGER >> len (equal 0x7 in this example). >>=20 >> One common problem I meet often (as I bind C often :) is >> this - address of open array argument is ot what it looks >> like. To be sure you are getting address of various UNTRACED >> REF..ARRAY.. and open array procedure arguments - use=20 >>=20 >> ADR(chars[0]) >>=20 >> and do not use: >>=20 >> LOOPHOLE(chars, ADDRESS) >>=20 >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >> Right now II downgraded my code to use strstr(3), but this >> argument passing still bugs me. >>=20 >> dd >>=20 >>=20 >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>=20 >> > What are the declarations of all the variables involved >> in the call? >> >=20 >> > And what is the actual error? Is it a SIGBUS, >> SIGSEGV? >> >=20 >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >> >> I had some error before I LOOPHOLEd it. >> >>=20 >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >> Benavides D. wrote: >> >>=20 >> >>> Hi all: >> >>> if chars is ADDRESS type why are you >> LOOPHOLE'ing it?=3D20 >> >>> Thanks in advance >> >>> =3D20 >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >> >> =3D >> >> escribi=3DC3=3DB3: >> >>> =3D20 >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >> >>>> Asunto: [M3devel] Problem interfacing C >> lib >> >>>> Para: "m3devel" >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >> >>>> #1 0x00000035bd8172a0 in >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >> what=3D3D0x7
> >>>> 0x7 out of bounds>, len=3D3D0, >> start=3D3D0x0, >> >>>> end=3D3D0x7fffffffdbb0) >> >>>> at buffer.c:2441 >> >>>> #2 0x0000000000404a0c in >> Buffer__Search (t=3D3D> >>>> reading variable>, pattern=3D3D> reading >> >>>> variable>, from=3D3D> variable>,=3D20 >> >>>> to=3D3D> variable>) at >> >>>> ../src/Buffer.m3:150 >> >>>> =3D20 >> >>>> Buffer.m3:150 >> >>>> pos :=3D3D >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >> ADDRESS), len, >> >>>> NIL, NIL); >> >>>> =3D20 >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >> is Utypes.size_t and >> >>>> it's value is 7. >> >>>> =3D20 >> >>>> <* EXTERNAL evbuffer_search_range *> >> >>>> PROCEDURE search_range(buf: t; what: >> char_star; len: size_t; >> >>>> start, end: UNTRACED REF ptr): ptr; >> >>>> =3D20 >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >> >>>> =3D20 >> >>>> Critical Mass Modula-3 version d5.9.0 >> >>>> last updated: 2010-07-21 >> >>>> compiled: 2010-10-04 07:24:16 >> >>>> configuration: /etc/cm3.cfg >> >>>> host: AMD64_LINUX >> >>>> target: AMD64_LINUX >> >>>> =3D20 >> >>>> =3D20 >> >>>> Any ideas? TIA, >> >>>> dd >> >>>> =3D20 >> >>>> =3D20 >>=20 >> From dabenavidesd at yahoo.es Wed Mar 21 04:30:42 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 03:30:42 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <1332300642.47039.YahooMailClassic@web29706.mail.ird.yahoo.com> Hi all: Even when types are very similar, there is still a susceptibility to hit range checking problems. This is true if you see a [-n-1 .. n] not exactly comparable with the CHAR enumeration type (not talking about representation base). So they are not subtypes of each other but also they are not subrange or included in the other as is. This problem would be ameliorated by having a range interval safe machine, not exactly amd64 :( Thanks in advance --- El mar, 20/3/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 17:06 > char_star is, at least in my > installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF > ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call > changes without > the <*EXTERNAL*> pragma... it shouldn't should > it? In which case, where > is chars passed, in pure Modula-3 code? I don't know > enough about the > standard ABI of amd64 to know what the code should look like > I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- > 61): > >it's allowed to have " ... a value of type ADDRESS to be > assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime > error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a > variable of type ADDRESS= > >. It is a checked runtime error if the variable does not > address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. > 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF > CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 > escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is > lesser > >> problem, I think. It looks like formal 'what' > is not > >> sent at all!? It's place is taken by next argument > - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often > :) is > >> this - address of open array argument is ot what it > looks > >> like. To be sure you are getting address of various > UNTRACED > >> REF..ARRAY.. and open array procedure arguments - > use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing > happened. > >> Right now II downgraded my code to use strstr(3), > but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables > involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a > SIGBUS, > >> SIGSEGV? > >> >=20 > >> > > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel > Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem > interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 > 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range > (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, > pattern=3D3D >> reading > >> >>>> variable>, from=3D3D reading > >> variable>,=3D20 > >> >>>> to=3D3D reading > >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos > :=3D3D > >> >>>> evbuffer.search_range(t.b, > LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is > chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL > evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; > what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): > ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so > on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version > d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> > From jay.krell at cornell.edu Wed Mar 21 05:35:37 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Mar 2012 04:35:37 +0000 Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com>, <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: That is a bit wierd. Lots of things seem wierd at first..and wierd even at second, but often there are reasons things are how they are, and often there are barriers to change. I would expect Ctypes.char = CHAR. But I don't know why it isn't. I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character.But it isn't. It is 8 bits and will never be larger. You are really best not to interface directly to C that you didn't write and the C that you write that you interface to, you are best restricting to a subset of C. And use m3-libs/m3core/src/unix for working examples. I remember when I added "BITS FOR" in Ctypes, it broke stuff.I either didn't commit that or later removed it, leaving things as theyhave been historically. - Jay > To: dabenavidesd at yahoo.es > Date: Tue, 20 Mar 2012 15:06:59 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Problem interfacing C lib > > char_star is, at least in my installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call changes without > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where > is chars passed, in pure Modula-3 code? I don't know enough about the > standard ABI of amd64 to know what the code should look like I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= > >. It is a checked runtime error if the variable does not address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser > >> problem, I think. It looks like formal 'what' is not > >> sent at all!? It's place is taken by next argument - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often :) is > >> this - address of open array argument is ot what it looks > >> like. To be sure you are getting address of various UNTRACED > >> REF..ARRAY.. and open array procedure arguments - use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. > >> Right now II downgraded my code to use strstr(3), but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a SIGBUS, > >> SIGSEGV? > >> >=20 > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, pattern=3D3D >> reading > >> >>>> variable>, from=3D3D >> variable>,=3D20 > >> >>>> to=3D3D >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos :=3D3D > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Wed Mar 21 08:28:30 2012 From: peter.mckinna at gmail.com (Peter McKinna) Date: Wed, 21 Mar 2012 18:28:30 +1100 Subject: [M3devel] cm3 on raspberry pi Message-ID: Hi Whats the status of the arm port for cm3? Just asking since there is a lot of interest in the new raspberry pi machine, the credit card sized linux box selling for $35 Regards Peter From microcode at zoho.com Wed Mar 21 09:34:31 2012 From: microcode at zoho.com (microcode at zoho.com) Date: Wed, 21 Mar 2012 08:34:31 +0000 Subject: [M3devel] cm3 on raspberry pi Message-ID: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> Selling but not shipping as far as I know. Is there any reason CM3 wouldn't run on it as opposed to other ARM Linux boxes? ------Original Message------ From: Peter McKinna To: m3devel at elegosoft.com Subject: [M3devel] cm3 on raspberry pi Sent: 21 Mar 2012 07:28 Hi Whats the status of the arm port for cm3? Just asking since there is a lot of interest in the new raspberry pi machine, the credit card sized linux box selling for $35 Regards Peter From dragisha at m3w.org Wed Mar 21 11:22:47 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 21 Mar 2012 11:22:47 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com>, <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). ===== struct evbuffer_ptr evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) { return evbuffer_search_range(buffer, what, len, start, NULL); } struct evbuffer_ptr evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) { On Mar 21, 2012, at 5:35 AM, Jay K wrote: > That is a bit wierd. > Lots of things seem wierd at first..and wierd even at second, > but often there are reasons things are how they are, > and often there are barriers to change. > > > I would expect Ctypes.char = CHAR. > > > But I don't know why it isn't. > > > I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. > But it isn't. It is 8 bits and will never be larger. > > > You are really best not to interface directly to C that you didn't write > and the C that you write that you interface to, you are best restricting > to a subset of C. > > > And use m3-libs/m3core/src/unix for working examples. > > > I remember when I added "BITS FOR" in Ctypes, it broke stuff. > I either didn't commit that or later removed it, leaving things as they > have been historically. > > > - Jay > > > To: dabenavidesd at yahoo.es > > Date: Tue, 20 Mar 2012 15:06:59 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Problem interfacing C lib > > > > char_star is, at least in my installation > > > > UNTRACED REF [-16_7f-1 .. 16_7f] > > > > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR > > > > However > > > > ADR(chars[0]) > > > > ought to be more or less precisely of the type char_star > > > > ... so I doubt that is the problem. > > > > I'm curious about whether the assembly code for the call changes without > > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where > > is chars passed, in pure Modula-3 code? I don't know enough about the > > standard ABI of amd64 to know what the code should look like I'm afraid. > > > > Mika > > > > "Daniel Alejandro Benavides D." writes: > > >Hi all: > > >I think the unchecked error lays down to: > > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): > > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= > > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = > > >does not address a variable of type T." > > > > > >which could be reads conversely as: > > > > > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= > > >. It is a checked runtime error if the variable does not address a var= > > >iable of type .T=20 > > >=20 > > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= > > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= > > >ication. > > >So maybe you need to change your char_star > > > > > >Thanks in advance > > > > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= > > >=B3: > > > > > >> De: Dragi=C5=A1a Duri=C4=87 > > >> Asunto: Re: [M3devel] Problem interfacing C lib > > >> Para: "Mika Nystrom" > > >> CC: m3devel at elegosoft.com > > >> Fecha: martes, 20 de marzo, 2012 01:04 > > >> Errorr is SIGSEGV. > > >>=20 > > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser > > >> problem, I think. It looks like formal 'what' is not > > >> sent at all!? It's place is taken by next argument - INTEGER > > >> len (equal 0x7 in this example). > > >>=20 > > >> One common problem I meet often (as I bind C often :) is > > >> this - address of open array argument is ot what it looks > > >> like. To be sure you are getting address of various UNTRACED > > >> REF..ARRAY.. and open array procedure arguments - use=20 > > >>=20 > > >> ADR(chars[0]) > > >>=20 > > >> and do not use: > > >>=20 > > >> LOOPHOLE(chars, ADDRESS) > > >>=20 > > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. > > >> Right now II downgraded my code to use strstr(3), but this > > >> argument passing still bugs me. > > >>=20 > > >> dd > > >>=20 > > >>=20 > > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > > >>=20 > > >> > What are the declarations of all the variables involved > > >> in the call? > > >> >=20 > > >> > And what is the actual error? Is it a SIGBUS, > > >> SIGSEGV? > > >> >=20 > > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > > >> >> I had some error before I LOOPHOLEd it. > > >> >>=20 > > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro > > >> Benavides D. wrote: > > >> >>=20 > > >> >>> Hi all: > > >> >>> if chars is ADDRESS type why are you > > >> LOOPHOLE'ing it?=3D20 > > >> >>> Thanks in advance > > >> >>> =3D20 > > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 > > >> > > >> =3D > > >> >> escribi=3DC3=3DB3: > > >> >>> =3D20 > > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 > > >> >>>> Asunto: [M3devel] Problem interfacing C > > >> lib > > >> >>>> Para: "m3devel" > > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 > > >> >>>> #1 0x00000035bd8172a0 in > > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, > > >> what=3D3D0x7
> >> >>>> 0x7 out of bounds>, len=3D3D0, > > >> start=3D3D0x0, > > >> >>>> end=3D3D0x7fffffffdbb0) > > >> >>>> at buffer.c:2441 > > >> >>>> #2 0x0000000000404a0c in > > >> Buffer__Search (t=3D3D > >> >>>> reading variable>, pattern=3D3D > >> reading > > >> >>>> variable>, from=3D3D > >> variable>,=3D20 > > >> >>>> to=3D3D > >> variable>) at > > >> >>>> ../src/Buffer.m3:150 > > >> >>>> =3D20 > > >> >>>> Buffer.m3:150 > > >> >>>> pos :=3D3D > > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, > > >> ADDRESS), len, > > >> >>>> NIL, NIL); > > >> >>>> =3D20 > > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len > > >> is Utypes.size_t and > > >> >>>> it's value is 7. > > >> >>>> =3D20 > > >> >>>> <* EXTERNAL evbuffer_search_range *> > > >> >>>> PROCEDURE search_range(buf: t; what: > > >> char_star; len: size_t; > > >> >>>> start, end: UNTRACED REF ptr): ptr; > > >> >>>> =3D20 > > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 > > >> >>>> =3D20 > > >> >>>> Critical Mass Modula-3 version d5.9.0 > > >> >>>> last updated: 2010-07-21 > > >> >>>> compiled: 2010-10-04 07:24:16 > > >> >>>> configuration: /etc/cm3.cfg > > >> >>>> host: AMD64_LINUX > > >> >>>> target: AMD64_LINUX > > >> >>>> =3D20 > > >> >>>> =3D20 > > >> >>>> Any ideas? TIA, > > >> >>>> dd > > >> >>>> =3D20 > > >> >>>> =3D20 > > >>=20 > > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Mar 21 12:31:30 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 11:31:30 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> Message-ID: <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. I wonder if it would be easier I think to handle. In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. Thanks in advance --- El mi?, 21/3/12, microcode at zoho.com escribi?: > De: microcode at zoho.com > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 21 de marzo, 2012 03:34 > Selling but not shipping as far as I > know. Is there any reason CM3 wouldn't run on it as opposed > to other ARM Linux boxes? > > ------Original Message------ > From: Peter McKinna > To: m3devel at elegosoft.com > Subject: [M3devel] cm3 on raspberry pi > Sent: 21 Mar 2012 07:28 > > Hi > > Whats the status of the arm port for cm3? > > Just asking since there is a lot of interest in the new > raspberry pi > machine, the credit card sized linux box selling for $35 > > Regards Peter > > > From dragisha at m3w.org Wed Mar 21 13:25:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 21 Mar 2012 13:25:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <* EXTERNAL evbuffer_search *> PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; <* EXTERNAL evbuffer_search_range *> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; Tried both void_star and UNTRACED REF? On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: > Can you show your M3 interface declarations for these? > > Sent from my iPad > > On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: > >> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >> >> ===== >> struct evbuffer_ptr >> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >> { >> return evbuffer_search_range(buffer, what, len, start, NULL); >> } >> >> struct evbuffer_ptr >> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >> { >> >> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >> >>> That is a bit wierd. >>> Lots of things seem wierd at first..and wierd even at second, >>> but often there are reasons things are how they are, >>> and often there are barriers to change. >>> >>> >>> I would expect Ctypes.char = CHAR. >>> >>> >>> But I don't know why it isn't. >>> >>> >>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>> But it isn't. It is 8 bits and will never be larger. >>> >>> >>> You are really best not to interface directly to C that you didn't write >>> and the C that you write that you interface to, you are best restricting >>> to a subset of C. >>> >>> >>> And use m3-libs/m3core/src/unix for working examples. >>> >>> >>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>> I either didn't commit that or later removed it, leaving things as they >>> have been historically. >>> >>> >>> - Jay >>> >>> > To: dabenavidesd at yahoo.es >>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>> > From: mika at async.caltech.edu >>> > CC: m3devel at elegosoft.com >>> > Subject: Re: [M3devel] Problem interfacing C lib >>> > >>> > char_star is, at least in my installation >>> > >>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>> > >>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>> > >>> > However >>> > >>> > ADR(chars[0]) >>> > >>> > ought to be more or less precisely of the type char_star >>> > >>> > ... so I doubt that is the problem. >>> > >>> > I'm curious about whether the assembly code for the call changes without >>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>> > >>> > Mika >>> > >>> > "Daniel Alejandro Benavides D." writes: >>> > >Hi all: >>> > >I think the unchecked error lays down to: >>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>> > >does not address a variable of type T." >>> > > >>> > >which could be reads conversely as: >>> > > >>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>> > >. It is a checked runtime error if the variable does not address a var= >>> > >iable of type .T=20 >>> > >=20 >>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>> > >ication. >>> > >So maybe you need to change your char_star >>> > > >>> > >Thanks in advance >>> > > >>> > > >>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>> > >=B3: >>> > > >>> > >> De: Dragi=C5=A1a Duri=C4=87 >>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>> > >> Para: "Mika Nystrom" >>> > >> CC: m3devel at elegosoft.com >>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>> > >> Errorr is SIGSEGV. >>> > >>=20 >>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>> > >> problem, I think. It looks like formal 'what' is not >>> > >> sent at all!? It's place is taken by next argument - INTEGER >>> > >> len (equal 0x7 in this example). >>> > >>=20 >>> > >> One common problem I meet often (as I bind C often :) is >>> > >> this - address of open array argument is ot what it looks >>> > >> like. To be sure you are getting address of various UNTRACED >>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>> > >>=20 >>> > >> ADR(chars[0]) >>> > >>=20 >>> > >> and do not use: >>> > >>=20 >>> > >> LOOPHOLE(chars, ADDRESS) >>> > >>=20 >>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>> > >> Right now II downgraded my code to use strstr(3), but this >>> > >> argument passing still bugs me. >>> > >>=20 >>> > >> dd >>> > >>=20 >>> > >>=20 >>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>> > >>=20 >>> > >> > What are the declarations of all the variables involved >>> > >> in the call? >>> > >> >=20 >>> > >> > And what is the actual error? Is it a SIGBUS, >>> > >> SIGSEGV? >>> > >> >=20 >>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>> > >> >> I had some error before I LOOPHOLEd it. >>> > >> >>=20 >>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>> > >> Benavides D. wrote: >>> > >> >>=20 >>> > >> >>> Hi all: >>> > >> >>> if chars is ADDRESS type why are you >>> > >> LOOPHOLE'ing it?=3D20 >>> > >> >>> Thanks in advance >>> > >> >>> =3D20 >>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>> > >> >>> > >> =3D >>> > >> >> escribi=3DC3=3DB3: >>> > >> >>> =3D20 >>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>> > >> lib >>> > >> >>>> Para: "m3devel" >>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>> > >> >>>> #1 0x00000035bd8172a0 in >>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>> > >> what=3D3D0x7
>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>> > >> start=3D3D0x0, >>> > >> >>>> end=3D3D0x7fffffffdbb0) >>> > >> >>>> at buffer.c:2441 >>> > >> >>>> #2 0x0000000000404a0c in >>> > >> Buffer__Search (t=3D3D>> > >> >>>> reading variable>, pattern=3D3D>> > >> reading >>> > >> >>>> variable>, from=3D3D>> > >> variable>,=3D20 >>> > >> >>>> to=3D3D>> > >> variable>) at >>> > >> >>>> ../src/Buffer.m3:150 >>> > >> >>>> =3D20 >>> > >> >>>> Buffer.m3:150 >>> > >> >>>> pos :=3D3D >>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>> > >> ADDRESS), len, >>> > >> >>>> NIL, NIL); >>> > >> >>>> =3D20 >>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>> > >> is Utypes.size_t and >>> > >> >>>> it's value is 7. >>> > >> >>>> =3D20 >>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>> > >> >>>> PROCEDURE search_range(buf: t; what: >>> > >> char_star; len: size_t; >>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>> > >> >>>> =3D20 >>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>> > >> >>>> =3D20 >>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>> > >> >>>> last updated: 2010-07-21 >>> > >> >>>> compiled: 2010-10-04 07:24:16 >>> > >> >>>> configuration: /etc/cm3.cfg >>> > >> >>>> host: AMD64_LINUX >>> > >> >>>> target: AMD64_LINUX >>> > >> >>>> =3D20 >>> > >> >>>> =3D20 >>> > >> >>>> Any ideas? TIA, >>> > >> >>>> dd >>> > >> >>>> =3D20 >>> > >> >>>> =3D20 >>> > >>=20 >>> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Mar 21 20:32:57 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 19:32:57 +0000 (GMT) Subject: [M3devel] Problem interfacing C lib In-Reply-To: <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: <1332358377.49563.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: What would you think of this LL (library language): http://www.ic.unicamp.br/~tomasz/projects/LL/LL.html http://www.ic.unicamp.br/~tomasz/projects/LL/LLpaper.ps.gz it looks nice, to me, it was supposed to generate Modula-3, nicer even! Thanks in advance --- El mar, 20/3/12, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] Problem interfacing C lib > Para: "Daniel Alejandro Benavides D." > CC: m3devel at elegosoft.com > Fecha: martes, 20 de marzo, 2012 17:06 > char_star is, at least in my > installation > > UNTRACED REF [-16_7f-1 .. 16_7f] > > But it's a good point that it's not actually an UNTRACED REF > ARRAY OF CHAR > > However > > ADR(chars[0]) > > ought to be more or less precisely of the type char_star > > ... so I doubt that is the problem. > > I'm curious about whether the assembly code for the call > changes without > the <*EXTERNAL*> pragma... it shouldn't should > it? In which case, where > is chars passed, in pure Modula-3 code? I don't know > enough about the > standard ABI of amd64 to know what the code should look like > I'm afraid. > > Mika > > "Daniel Alejandro Benavides D." writes: > >Hi all: > >I think the unchecked error lays down to: > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- > 61): > >it's allowed to have " ... a value of type ADDRESS to be > assigned to a vari= > >able of type UNTRACED REF T. It is an unchecked runtime > error if the value = > >does not address a variable of type T." > > > >which could be reads conversely as: > > > >a value of type UNTRACED REF T to be assigned to a > variable of type ADDRESS= > >. It is a checked runtime error if the variable does not > address a var= > >iable of type .T=20 > >=20 > >And because because char_star is a subrange [-128 .. > 127] OF INTEGER (and n= > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF > CHAR erro is cf. the specif= > >ication. > >So maybe you need to change your char_star > > > >Thanks in advance > > > > > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 > escribi=C3= > >=B3: > > > >> De: Dragi=C5=A1a Duri=C4=87 > >> Asunto: Re: [M3devel] Problem interfacing C lib > >> Para: "Mika Nystrom" > >> CC: m3devel at elegosoft.com > >> Fecha: martes, 20 de marzo, 2012 01:04 > >> Errorr is SIGSEGV. > >>=20 > >> chars is UNTRACED REF ARRAY OF CHAR but it is > lesser > >> problem, I think. It looks like formal 'what' > is not > >> sent at all!? It's place is taken by next argument > - INTEGER > >> len (equal 0x7 in this example). > >>=20 > >> One common problem I meet often (as I bind C often > :) is > >> this - address of open array argument is ot what it > looks > >> like. To be sure you are getting address of various > UNTRACED > >> REF..ARRAY.. and open array procedure arguments - > use=20 > >>=20 > >> ADR(chars[0]) > >>=20 > >> and do not use: > >>=20 > >> LOOPHOLE(chars, ADDRESS) > >>=20 > >> Of course, I tried ADR(chars[0]) :) - Same thing > happened. > >> Right now II downgraded my code to use strstr(3), > but this > >> argument passing still bugs me. > >>=20 > >> dd > >>=20 > >>=20 > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: > >>=20 > >> > What are the declarations of all the variables > involved > >> in the call? > >> >=20 > >> > And what is the actual error? Is it a > SIGBUS, > >> SIGSEGV? > >> >=20 > >> > > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: > >> >> I had some error before I LOOPHOLEd it. > >> >>=20 > >> >> On Mar 19, 2012, at 7:27 PM, Daniel > Alejandro > >> Benavides D. wrote: > >> >>=20 > >> >>> Hi all: > >> >>> if chars is ADDRESS type why are you > >> LOOPHOLE'ing it?=3D20 > >> >>> Thanks in advance > >> >>> =3D20 > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> > >> =3D > >> >> escribi=3DC3=3DB3: > >> >>> =3D20 > >> >>>> De: Dragi=3DC5=3DA1a > Duri=3DC4=3D87 > >> >>>> Asunto: [M3devel] Problem > interfacing C > >> lib > >> >>>> Para: "m3devel" > >> >>>> Fecha: lunes, 19 de marzo, 2012 > 12:13 > >> >>>> #1 0x00000035bd8172a0 in > >> >>>> evbuffer_search_range > (buffer=3D3D0x694090, > >> what=3D3D0x7
>> >>>> 0x7 out of bounds>, len=3D3D0, > >> start=3D3D0x0, > >> >>>> end=3D3D0x7fffffffdbb0) > >> >>>> at buffer.c:2441 > >> >>>> #2 0x0000000000404a0c in > >> Buffer__Search (t=3D3D >> >>>> reading variable>, > pattern=3D3D >> reading > >> >>>> variable>, from=3D3D reading > >> variable>,=3D20 > >> >>>> to=3D3D reading > >> variable>) at > >> >>>> ../src/Buffer.m3:150 > >> >>>> =3D20 > >> >>>> Buffer.m3:150 > >> >>>> pos > :=3D3D > >> >>>> evbuffer.search_range(t.b, > LOOPHOLE(chars, > >> ADDRESS), len, > >> >>>> NIL, NIL); > >> >>>> =3D20 > >> >>>> t.b is a pointer, so is > chars=3DE2=3D80=3DA6 len > >> is Utypes.size_t and > >> >>>> it's value is 7. > >> >>>> =3D20 > >> >>>> <* EXTERNAL > evbuffer_search_range *> > >> >>>> PROCEDURE search_range(buf: t; > what: > >> char_star; len: size_t; > >> >>>> start, end: UNTRACED REF ptr): > ptr; > >> >>>> =3D20 > >> >>>> t is an ADDRESS, and so > on=3DE2=3D80=3DA6 > >> >>>> =3D20 > >> >>>> Critical Mass Modula-3 version > d5.9.0 > >> >>>> last updated: 2010-07-21 > >> >>>> compiled: 2010-10-04 07:24:16 > >> >>>> configuration: /etc/cm3.cfg > >> >>>> host: AMD64_LINUX > >> >>>> target: AMD64_LINUX > >> >>>> =3D20 > >> >>>> =3D20 > >> >>>> Any ideas? TIA, > >> >>>> dd > >> >>>> =3D20 > >> >>>> =3D20 > >>=20 > >> > From jay.krell at cornell.edu Wed Mar 21 20:35:13 2012 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Mar 2012 12:35:13 -0700 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: Not good: don't return structs by value. Pass a pointer to where you want the result. - Jay (briefly/pocket-sized-computer-aka-phone) On Mar 21, 2012, at 5:25 AM, Dragi?a Duri? wrote: > <* EXTERNAL evbuffer_search *> > PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; > > <* EXTERNAL evbuffer_search_range *> > PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; > > Tried both void_star and UNTRACED REF? > > On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: > >> Can you show your M3 interface declarations for these? >> >> Sent from my iPad >> >> On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: >> >>> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >>> >>> ===== >>> struct evbuffer_ptr >>> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >>> { >>> return evbuffer_search_range(buffer, what, len, start, NULL); >>> } >>> >>> struct evbuffer_ptr >>> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >>> { >>> >>> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >>> >>>> That is a bit wierd. >>>> Lots of things seem wierd at first..and wierd even at second, >>>> but often there are reasons things are how they are, >>>> and often there are barriers to change. >>>> >>>> >>>> I would expect Ctypes.char = CHAR. >>>> >>>> >>>> But I don't know why it isn't. >>>> >>>> >>>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>>> But it isn't. It is 8 bits and will never be larger. >>>> >>>> >>>> You are really best not to interface directly to C that you didn't write >>>> and the C that you write that you interface to, you are best restricting >>>> to a subset of C. >>>> >>>> >>>> And use m3-libs/m3core/src/unix for working examples. >>>> >>>> >>>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>>> I either didn't commit that or later removed it, leaving things as they >>>> have been historically. >>>> >>>> >>>> - Jay >>>> >>>> > To: dabenavidesd at yahoo.es >>>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>>> > From: mika at async.caltech.edu >>>> > CC: m3devel at elegosoft.com >>>> > Subject: Re: [M3devel] Problem interfacing C lib >>>> > >>>> > char_star is, at least in my installation >>>> > >>>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>>> > >>>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>>> > >>>> > However >>>> > >>>> > ADR(chars[0]) >>>> > >>>> > ought to be more or less precisely of the type char_star >>>> > >>>> > ... so I doubt that is the problem. >>>> > >>>> > I'm curious about whether the assembly code for the call changes without >>>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>>> > >>>> > Mika >>>> > >>>> > "Daniel Alejandro Benavides D." writes: >>>> > >Hi all: >>>> > >I think the unchecked error lays down to: >>>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>>> > >does not address a variable of type T." >>>> > > >>>> > >which could be reads conversely as: >>>> > > >>>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>>> > >. It is a checked runtime error if the variable does not address a var= >>>> > >iable of type .T=20 >>>> > >=20 >>>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>>> > >ication. >>>> > >So maybe you need to change your char_star >>>> > > >>>> > >Thanks in advance >>>> > > >>>> > > >>>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>>> > >=B3: >>>> > > >>>> > >> De: Dragi=C5=A1a Duri=C4=87 >>>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>>> > >> Para: "Mika Nystrom" >>>> > >> CC: m3devel at elegosoft.com >>>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>>> > >> Errorr is SIGSEGV. >>>> > >>=20 >>>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>>> > >> problem, I think. It looks like formal 'what' is not >>>> > >> sent at all!? It's place is taken by next argument - INTEGER >>>> > >> len (equal 0x7 in this example). >>>> > >>=20 >>>> > >> One common problem I meet often (as I bind C often :) is >>>> > >> this - address of open array argument is ot what it looks >>>> > >> like. To be sure you are getting address of various UNTRACED >>>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>>> > >>=20 >>>> > >> ADR(chars[0]) >>>> > >>=20 >>>> > >> and do not use: >>>> > >>=20 >>>> > >> LOOPHOLE(chars, ADDRESS) >>>> > >>=20 >>>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>>> > >> Right now II downgraded my code to use strstr(3), but this >>>> > >> argument passing still bugs me. >>>> > >>=20 >>>> > >> dd >>>> > >>=20 >>>> > >>=20 >>>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>>> > >>=20 >>>> > >> > What are the declarations of all the variables involved >>>> > >> in the call? >>>> > >> >=20 >>>> > >> > And what is the actual error? Is it a SIGBUS, >>>> > >> SIGSEGV? >>>> > >> >=20 >>>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>>> > >> >> I had some error before I LOOPHOLEd it. >>>> > >> >>=20 >>>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>>> > >> Benavides D. wrote: >>>> > >> >>=20 >>>> > >> >>> Hi all: >>>> > >> >>> if chars is ADDRESS type why are you >>>> > >> LOOPHOLE'ing it?=3D20 >>>> > >> >>> Thanks in advance >>>> > >> >>> =3D20 >>>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>> > >> >>>> > >> =3D >>>> > >> >> escribi=3DC3=3DB3: >>>> > >> >>> =3D20 >>>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>>> > >> lib >>>> > >> >>>> Para: "m3devel" >>>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>> > >> >>>> #1 0x00000035bd8172a0 in >>>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>>> > >> what=3D3D0x7
>>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>>> > >> start=3D3D0x0, >>>> > >> >>>> end=3D3D0x7fffffffdbb0) >>>> > >> >>>> at buffer.c:2441 >>>> > >> >>>> #2 0x0000000000404a0c in >>>> > >> Buffer__Search (t=3D3D>>> > >> >>>> reading variable>, pattern=3D3D>>> > >> reading >>>> > >> >>>> variable>, from=3D3D>>> > >> variable>,=3D20 >>>> > >> >>>> to=3D3D>>> > >> variable>) at >>>> > >> >>>> ../src/Buffer.m3:150 >>>> > >> >>>> =3D20 >>>> > >> >>>> Buffer.m3:150 >>>> > >> >>>> pos :=3D3D >>>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>>> > >> ADDRESS), len, >>>> > >> >>>> NIL, NIL); >>>> > >> >>>> =3D20 >>>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>>> > >> is Utypes.size_t and >>>> > >> >>>> it's value is 7. >>>> > >> >>>> =3D20 >>>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>>> > >> >>>> PROCEDURE search_range(buf: t; what: >>>> > >> char_star; len: size_t; >>>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>>> > >> >>>> =3D20 >>>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>>> > >> >>>> =3D20 >>>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>>> > >> >>>> last updated: 2010-07-21 >>>> > >> >>>> compiled: 2010-10-04 07:24:16 >>>> > >> >>>> configuration: /etc/cm3.cfg >>>> > >> >>>> host: AMD64_LINUX >>>> > >> >>>> target: AMD64_LINUX >>>> > >> >>>> =3D20 >>>> > >> >>>> =3D20 >>>> > >> >>>> Any ideas? TIA, >>>> > >> >>>> dd >>>> > >> >>>> =3D20 >>>> > >> >>>> =3D20 >>>> > >>=20 >>>> > >> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Mar 21 23:01:07 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 21 Mar 2012 18:01:07 -0400 Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> References: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> Message-ID: <20120321220107.GA21387@topoi.pooq.com> On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. > I wonder if it would be easier I think to handle. > In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. > The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. > Thanks in advance While we're speculating, is there any chance SPIN would run on it? -- hendrik From dabenavidesd at yahoo.es Wed Mar 21 23:27:52 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 21 Mar 2012 22:27:52 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <20120321220107.GA21387@topoi.pooq.com> Message-ID: <1332368872.19833.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: I think we could, but I would center my focus on a Traditional Microkernel approach e.g Workplace OS (so, you could have instead of a Unix kernel level server on top of SPIN kernel) a personality in whatever language OS (Gnu/Linux, or better to say, M3/Linux) you want, in user mode (the larger part would be rewriting of lowest level of Mach, but ARX did that before it, abstraction of everything), even I know they ported AIX to Modula-3 at some point in the project. Thanks in advance --- El mi?, 21/3/12, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 21 de marzo, 2012 17:01 > On Wed, Mar 21, 2012 at 11:31:30AM > +0000, Daniel Alejandro Benavides D. wrote: > > Hi all: > > las t I thing I heard it changed from USB stick to > credit card sized, but I wonder if the USB stick is > available in any of Models. > > I wonder if it would be easier I think to handle. > > In any case, this good stuff to test a cross compiler, > I believe it is ARM32_LINUX, or so, but it would be > something akin Android phone-likes thing. > > The other question I was wondering if we can put on it > the ARX (because RIOS OS is adapting their OS as a third > party), they have told have they can emulate the thing for > now with a VM developed for their OS. > > Thanks in advance > > While we're speculating, is there any chance SPIN would run > on it? > > -- hendrik > From dragisha at m3w.org Thu Mar 22 12:08:10 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 22 Mar 2012 12:08:10 +0100 Subject: [M3devel] Problem interfacing C lib In-Reply-To: References: <1332279094.50118.YahooMailClassic@web29702.mail.ird.yahoo.com> <20120320220659.9136A1A207C@async.async.caltech.edu> Message-ID: I'll try it soon, but I believe you are right. That is only place in whole libevent where I met with struct return value. Everything else I tried works good. dd On Mar 21, 2012, at 8:35 PM, Jay wrote: > Not good: don't return structs by value. Pass a pointer to where you want the result. > > - Jay (briefly/pocket-sized-computer-aka-phone) > > On Mar 21, 2012, at 5:25 AM, Dragi?a Duri? wrote: > >> <* EXTERNAL evbuffer_search *> >> PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr; >> >> <* EXTERNAL evbuffer_search_range *> >> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr; >> >> Tried both void_star and UNTRACED REF? >> >> On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote: >> >>> Can you show your M3 interface declarations for these? >>> >>> Sent from my iPad >>> >>> On Mar 21, 2012, at 6:22 AM, Dragi?a Duri? wrote: >>> >>>> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :). >>>> >>>> ===== >>>> struct evbuffer_ptr >>>> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start) >>>> { >>>> return evbuffer_search_range(buffer, what, len, start, NULL); >>>> } >>>> >>>> struct evbuffer_ptr >>>> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end) >>>> { >>>> >>>> On Mar 21, 2012, at 5:35 AM, Jay K wrote: >>>> >>>>> That is a bit wierd. >>>>> Lots of things seem wierd at first..and wierd even at second, >>>>> but often there are reasons things are how they are, >>>>> and often there are barriers to change. >>>>> >>>>> >>>>> I would expect Ctypes.char = CHAR. >>>>> >>>>> >>>>> But I don't know why it isn't. >>>>> >>>>> >>>>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character. >>>>> But it isn't. It is 8 bits and will never be larger. >>>>> >>>>> >>>>> You are really best not to interface directly to C that you didn't write >>>>> and the C that you write that you interface to, you are best restricting >>>>> to a subset of C. >>>>> >>>>> >>>>> And use m3-libs/m3core/src/unix for working examples. >>>>> >>>>> >>>>> I remember when I added "BITS FOR" in Ctypes, it broke stuff. >>>>> I either didn't commit that or later removed it, leaving things as they >>>>> have been historically. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> > To: dabenavidesd at yahoo.es >>>>> > Date: Tue, 20 Mar 2012 15:06:59 -0700 >>>>> > From: mika at async.caltech.edu >>>>> > CC: m3devel at elegosoft.com >>>>> > Subject: Re: [M3devel] Problem interfacing C lib >>>>> > >>>>> > char_star is, at least in my installation >>>>> > >>>>> > UNTRACED REF [-16_7f-1 .. 16_7f] >>>>> > >>>>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR >>>>> > >>>>> > However >>>>> > >>>>> > ADR(chars[0]) >>>>> > >>>>> > ought to be more or less precisely of the type char_star >>>>> > >>>>> > ... so I doubt that is the problem. >>>>> > >>>>> > I'm curious about whether the assembly code for the call changes without >>>>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where >>>>> > is chars passed, in pure Modula-3 code? I don't know enough about the >>>>> > standard ABI of amd64 to know what the code should look like I'm afraid. >>>>> > >>>>> > Mika >>>>> > >>>>> > "Daniel Alejandro Benavides D." writes: >>>>> > >Hi all: >>>>> > >I think the unchecked error lays down to: >>>>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61): >>>>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari= >>>>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value = >>>>> > >does not address a variable of type T." >>>>> > > >>>>> > >which could be reads conversely as: >>>>> > > >>>>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS= >>>>> > >. It is a checked runtime error if the variable does not address a var= >>>>> > >iable of type .T=20 >>>>> > >=20 >>>>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n= >>>>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif= >>>>> > >ication. >>>>> > >So maybe you need to change your char_star >>>>> > > >>>>> > >Thanks in advance >>>>> > > >>>>> > > >>>>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 escribi=C3= >>>>> > >=B3: >>>>> > > >>>>> > >> De: Dragi=C5=A1a Duri=C4=87 >>>>> > >> Asunto: Re: [M3devel] Problem interfacing C lib >>>>> > >> Para: "Mika Nystrom" >>>>> > >> CC: m3devel at elegosoft.com >>>>> > >> Fecha: martes, 20 de marzo, 2012 01:04 >>>>> > >> Errorr is SIGSEGV. >>>>> > >>=20 >>>>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser >>>>> > >> problem, I think. It looks like formal 'what' is not >>>>> > >> sent at all!? It's place is taken by next argument - INTEGER >>>>> > >> len (equal 0x7 in this example). >>>>> > >>=20 >>>>> > >> One common problem I meet often (as I bind C often :) is >>>>> > >> this - address of open array argument is ot what it looks >>>>> > >> like. To be sure you are getting address of various UNTRACED >>>>> > >> REF..ARRAY.. and open array procedure arguments - use=20 >>>>> > >>=20 >>>>> > >> ADR(chars[0]) >>>>> > >>=20 >>>>> > >> and do not use: >>>>> > >>=20 >>>>> > >> LOOPHOLE(chars, ADDRESS) >>>>> > >>=20 >>>>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened. >>>>> > >> Right now II downgraded my code to use strstr(3), but this >>>>> > >> argument passing still bugs me. >>>>> > >>=20 >>>>> > >> dd >>>>> > >>=20 >>>>> > >>=20 >>>>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote: >>>>> > >>=20 >>>>> > >> > What are the declarations of all the variables involved >>>>> > >> in the call? >>>>> > >> >=20 >>>>> > >> > And what is the actual error? Is it a SIGBUS, >>>>> > >> SIGSEGV? >>>>> > >> >=20 >>>>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes: >>>>> > >> >> I had some error before I LOOPHOLEd it. >>>>> > >> >>=20 >>>>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro >>>>> > >> Benavides D. wrote: >>>>> > >> >>=20 >>>>> > >> >>> Hi all: >>>>> > >> >>> if chars is ADDRESS type why are you >>>>> > >> LOOPHOLE'ing it?=3D20 >>>>> > >> >>> Thanks in advance >>>>> > >> >>> =3D20 >>>>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>>> > >> >>>>> > >> =3D >>>>> > >> >> escribi=3DC3=3DB3: >>>>> > >> >>> =3D20 >>>>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 >>>>> > >> >>>> Asunto: [M3devel] Problem interfacing C >>>>> > >> lib >>>>> > >> >>>> Para: "m3devel" >>>>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13 >>>>> > >> >>>> #1 0x00000035bd8172a0 in >>>>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090, >>>>> > >> what=3D3D0x7
>>>> > >> >>>> 0x7 out of bounds>, len=3D3D0, >>>>> > >> start=3D3D0x0, >>>>> > >> >>>> end=3D3D0x7fffffffdbb0) >>>>> > >> >>>> at buffer.c:2441 >>>>> > >> >>>> #2 0x0000000000404a0c in >>>>> > >> Buffer__Search (t=3D3D>>>> > >> >>>> reading variable>, pattern=3D3D>>>> > >> reading >>>>> > >> >>>> variable>, from=3D3D>>>> > >> variable>,=3D20 >>>>> > >> >>>> to=3D3D>>>> > >> variable>) at >>>>> > >> >>>> ../src/Buffer.m3:150 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Buffer.m3:150 >>>>> > >> >>>> pos :=3D3D >>>>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars, >>>>> > >> ADDRESS), len, >>>>> > >> >>>> NIL, NIL); >>>>> > >> >>>> =3D20 >>>>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len >>>>> > >> is Utypes.size_t and >>>>> > >> >>>> it's value is 7. >>>>> > >> >>>> =3D20 >>>>> > >> >>>> <* EXTERNAL evbuffer_search_range *> >>>>> > >> >>>> PROCEDURE search_range(buf: t; what: >>>>> > >> char_star; len: size_t; >>>>> > >> >>>> start, end: UNTRACED REF ptr): ptr; >>>>> > >> >>>> =3D20 >>>>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Critical Mass Modula-3 version d5.9.0 >>>>> > >> >>>> last updated: 2010-07-21 >>>>> > >> >>>> compiled: 2010-10-04 07:24:16 >>>>> > >> >>>> configuration: /etc/cm3.cfg >>>>> > >> >>>> host: AMD64_LINUX >>>>> > >> >>>> target: AMD64_LINUX >>>>> > >> >>>> =3D20 >>>>> > >> >>>> =3D20 >>>>> > >> >>>> Any ideas? TIA, >>>>> > >> >>>> dd >>>>> > >> >>>> =3D20 >>>>> > >> >>>> =3D20 >>>>> > >>=20 >>>>> > >> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Mar 22 12:08:53 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 22 Mar 2012 12:08:53 +0100 Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <20120321220107.GA21387@topoi.pooq.com> References: <387769193-1332318854-cardhu_decombobulator_blackberry.rim.net-1100998881-@b3.c1.bise3.blackberry> <1332329490.14433.YahooMailClassic@web29705.mail.ird.yahoo.com> <20120321220107.GA21387@topoi.pooq.com> Message-ID: <527A0212-B595-4D2D-9126-79BF9C762F57@m3w.org> Do we have all parts of SPIN? And do we have a right to modify it, etc etc? On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel Alejandro Benavides D. wrote: >> Hi all: >> las t I thing I heard it changed from USB stick to credit card sized, but I wonder if the USB stick is available in any of Models. >> I wonder if it would be easier I think to handle. >> In any case, this good stuff to test a cross compiler, I believe it is ARM32_LINUX, or so, but it would be something akin Android phone-likes thing. >> The other question I was wondering if we can put on it the ARX (because RIOS OS is adapting their OS as a third party), they have told have they can emulate the thing for now with a VM developed for their OS. >> Thanks in advance > > While we're speculating, is there any chance SPIN would run on it? > > -- hendrik From dabenavidesd at yahoo.es Thu Mar 22 13:24:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 22 Mar 2012 12:24:25 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <527A0212-B595-4D2D-9126-79BF9C762F57@m3w.org> Message-ID: <1332419065.77273.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: I think they further developed source kernel, but several parts of it like the kernel drivers are left up to each one to setup (and as far as I know, they didn't want to open the ALPHA port, but the SPINE project would replace/update that port, I mean who cares an Alpha this days, unless you had something big there). However the Unix emulation server was more advanced in the Alpha port. However DEC UNIX server would matter only to anyone with that system, anyone? Thanks in advance --- El jue, 22/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: "Hendrik Boom" > CC: m3devel at elegosoft.com > Fecha: jueves, 22 de marzo, 2012 06:08 > Do we have all parts of SPIN? And do > we have a right to modify it, etc etc? > > On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > > > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel > Alejandro Benavides D. wrote: > >> Hi all: > >> las t I thing I heard it changed from USB stick to > credit card sized, but I wonder if the USB stick is > available in any of Models. > >> I wonder if it would be easier I think to handle. > >> In any case, this good stuff to test a cross > compiler, I believe it is ARM32_LINUX, or so, but it would > be something akin Android phone-likes thing. > >> The other question I was wondering if we can put on > it the ARX (because RIOS OS is adapting their OS as a third > party), they have told have they can emulate the thing for > now with a VM developed for their OS. > >> Thanks in advance > > > > While we're speculating, is there any chance SPIN would > run on it? > > > > -- hendrik > > From dabenavidesd at yahoo.es Fri Mar 23 16:50:36 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 23 Mar 2012 15:50:36 +0000 (GMT) Subject: [M3devel] cm3 on raspberry pi In-Reply-To: <1332419065.77273.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: <1332517836.93069.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: And as it happens, and other OS projects have died just because of that component in their OSes. My goal would be like this (based on some suppositions of course, but I'm almost certain of the following): - Modula-3 would allows to create a development environment capable of doing the hardest work, but will easy the self-construction of: - A driver manager system or sub-system, included in the micro-kernel, e.g Mach or ARX, or SPIN - A compiler self-trusted (currently SPIN just certifies based on type-checking but not any other static or at all procedure that I know) harvesting of trust, in which Baby Modula-3 self-constructing compiler would help to improve the most interesting parts of the compiler itself. - Development of specifications from documentation *available* of controllers. - Method implementations of them being written by hand, or with some sort of hackers help. - Self-checking of the above, and more static analysis techniques. - After we develop that, then it is time to implement the rest systematically, on architecture basic features grounds, which would allows us if possible to detect from existing drivers creation of new device drivers automatically. Possible target languages are logical ones, since most of drivers are written in assembly, then why not implemented in a logical manner (a.k.a NEC's LIME). Mika you have a Scheme interpreter, what is the status of that? Thanks in advance --- El jue, 22/3/12, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] cm3 on raspberry pi > Para: "Hendrik Boom" , "Dragi?a Duri?" > CC: m3devel at elegosoft.com > Fecha: jueves, 22 de marzo, 2012 07:24 > Hi all: > I think they further developed source kernel, but several > parts of it like the kernel drivers are left up to each one > to setup (and as far as I know, they didn't want to open the > ALPHA port, but the SPINE project would replace/update that > port, I mean who cares an Alpha this days, unless you had > something big there). However the Unix emulation server was > more advanced in the Alpha port. However DEC UNIX server > would matter only to anyone with that system, anyone? > Thanks in advance > > --- El jue, 22/3/12, Dragi?a Duri? > escribi?: > > > De: Dragi?a Duri? > > Asunto: Re: [M3devel] cm3 on raspberry pi > > Para: "Hendrik Boom" > > CC: m3devel at elegosoft.com > > Fecha: jueves, 22 de marzo, 2012 06:08 > > Do we have all parts of SPIN? And do > > we have a right to modify it, etc etc? > > > > On Mar 21, 2012, at 11:01 PM, Hendrik Boom wrote: > > > > > On Wed, Mar 21, 2012 at 11:31:30AM +0000, Daniel > > Alejandro Benavides D. wrote: > > >> Hi all: > > >> las t I thing I heard it changed from USB > stick to > > credit card sized, but I wonder if the USB stick is > > available in any of Models. > > >> I wonder if it would be easier I think to > handle. > > >> In any case, this good stuff to test a cross > > compiler, I believe it is ARM32_LINUX, or so, but it > would > > be something akin Android phone-likes thing. > > >> The other question I was wondering if we can > put on > > it the ARX (because RIOS OS is adapting their OS as a > third > > party), they have told have they can emulate the thing > for > > now with a VM developed for their OS. > > >> Thanks in advance > > > > > > While we're speculating, is there any chance SPIN > would > > run on it? > > > > > > -- hendrik > > > > > From dragisha at m3w.org Sat Mar 24 12:27:06 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 24 Mar 2012 12:27:06 +0100 Subject: [M3devel] Status of ARM_DARWIN? Message-ID: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> Anybody using it? From dragisha at m3w.org Sat Mar 24 23:12:06 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 24 Mar 2012 23:12:06 +0100 Subject: [M3devel] quake c_source, gcc -I directive Message-ID: <8312AB2C-A725-4F9D-942B-9D7DE8A48E63@m3w.org> Anybody worked out an easy method resembling import_lib() to inform C compiler where to find include files in case it is not /usr/include? Like when I am using fink on a Mac, for example. TIA, dd From dragisha at m3w.org Sun Mar 25 00:41:31 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 00:41:31 +0100 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> Message-ID: <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o My question is, can I dd -I/sw/include so if my source has #include It will be found in /sw/include/event2/event.h Of course, /usr/include, for system .h's, should work at same time. dd On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: > Hi all: > I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D > But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. > > > Thanks in advance > > --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > >> De: Dragi?a Duri? >> Asunto: [M3devel] quake c_source, gcc -I directive >> Para: "m3devel" >> Fecha: s?bado, 24 de marzo, 2012 17:12 >> Anybody worked out an easy method >> resembling import_lib() to inform C compiler where to find >> include files in case it is not /usr/include? Like when I am >> using fink on a Mac, for example. >> >> TIA, >> dd >> >> From dabenavidesd at yahoo.es Sun Mar 25 00:37:49 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 24 Mar 2012 23:37:49 +0000 (GMT) Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <8312AB2C-A725-4F9D-942B-9D7DE8A48E63@m3w.org> Message-ID: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. Thanks in advance --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] quake c_source, gcc -I directive > Para: "m3devel" > Fecha: s?bado, 24 de marzo, 2012 17:12 > Anybody worked out an easy method > resembling import_lib() to inform C compiler where to find > include files in case it is not /usr/include? Like when I am > using fink on a Mac, for example. > > TIA, > dd > > From dabenavidesd at yahoo.es Sun Mar 25 01:07:44 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 25 Mar 2012 00:07:44 +0000 (GMT) Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> Message-ID: <1332634064.98273.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: Maybe you need to create a package for that thing there /sw/include/event and create a symbolic link to it named src and compile and ship it. Then you would import the package as everything. Wouldn't it? Thanks in advance --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: Re: [M3devel] quake c_source, gcc -I directive > Para: "Daniel Alejandro Benavides D." > CC: "m3devel" > Fecha: s?bado, 24 de marzo, 2012 18:41 > c_source("file") will compile file.c > in same directory as m3makefile with that line is. And put > object in ../$TARGET/file.o > > My question is, can I dd -I/sw/include so if my source has > > #include > > It will be found in /sw/include/event2/event.h > > Of course, /usr/include, for system .h's, should work at > same time. > > dd > > > On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. > wrote: > > > Hi all: > > I thought the c_source file had to be named in the same > way your modula-3 sources (src), but for any other purposes > like finding utilities inside your src tree src/D > > But if that's not the implementation you need but to > link against I had to actually call the var outside the > Modula-3 environment to override it in Modula-3 system > linker. > > > > > > Thanks in advance > > > > --- El s?b, 24/3/12, Dragi?a Duri? > escribi?: > > > >> De: Dragi?a Duri? > >> Asunto: [M3devel] quake c_source, gcc -I directive > >> Para: "m3devel" > >> Fecha: s?bado, 24 de marzo, 2012 17:12 > >> Anybody worked out an easy method > >> resembling import_lib() to inform C compiler where > to find > >> include files in case it is not /usr/include? Like > when I am > >> using fink on a Mac, for example. > >> > >> TIA, > >> dd > >> > >> > > From darko at darko.org Sun Mar 25 06:55:17 2012 From: darko at darko.org (Darko) Date: Sat, 24 Mar 2012 21:55:17 -0700 Subject: [M3devel] Status of ARM_DARWIN? In-Reply-To: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> References: <8321CD35-4EF1-4CE7-9E0E-110045BB3822@m3w.org> Message-ID: <4925F43C-C418-4507-8038-C63408495220@darko.org> I don't think it works right now. I think native ARM_DARWIN and ARM_LINUX implementations would be a blessing given the proliferation of ARM devices, though. On 24/03/2012, at 4:27 AM, Dragi?a Duri? wrote: > Anybody using it? From dragisha at m3w.org Sun Mar 25 09:46:13 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 09:46:13 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> Message-ID: <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org> Read through Darwin.common,Unix.common? No mention. SYSTEM_LIBS is for -L dd On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: > Can you not augment the standard system .h include paths as per the m3.cfg? > > On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: > >> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o >> >> My question is, can I dd -I/sw/include so if my source has >> >> #include >> >> It will be found in /sw/include/event2/event.h >> >> Of course, /usr/include, for system .h's, should work at same time. >> >> dd >> >> >> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: >> >>> Hi all: >>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D >>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. >>> >>> >>> Thanks in advance >>> >>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: >>> >>>> De: Dragi?a Duri? >>>> Asunto: [M3devel] quake c_source, gcc -I directive >>>> Para: "m3devel" >>>> Fecha: s?bado, 24 de marzo, 2012 17:12 >>>> Anybody worked out an easy method >>>> resembling import_lib() to inform C compiler where to find >>>> include files in case it is not /usr/include? Like when I am >>>> using fink on a Mac, for example. >>>> >>>> TIA, >>>> dd >>>> >>>> >> > From dragisha at m3w.org Sun Mar 25 21:33:18 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 25 Mar 2012 21:33:18 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com> <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org> <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com> <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org> Message-ID: I tried obvious thing :) "/Users/dragisha/m3/libevent/src/m3makefile", line 9: quake runtime error: wrong number of parameters passed to procedure c_source (expected 1, received 2) On Mar 25, 2012, at 3:49 PM, Antony Hosking wrote: > I am sure there is a way to do what you want with a simple one-liner in the m3makefile. > Anyone remember? > > On Mar 25, 2012, at 3:46 AM, Dragi?a Duri? wrote: > >> Read through Darwin.common,Unix.common? No mention. >> >> SYSTEM_LIBS is for -L >> >> dd >> >> On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: >> >>> Can you not augment the standard system .h include paths as per the m3.cfg? >>> >>> On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: >>> >>>> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o >>>> >>>> My question is, can I dd -I/sw/include so if my source has >>>> >>>> #include >>>> >>>> It will be found in /sw/include/event2/event.h >>>> >>>> Of course, /usr/include, for system .h's, should work at same time. >>>> >>>> dd >>>> >>>> >>>> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: >>>> >>>>> Hi all: >>>>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D >>>>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. >>>>> >>>>> >>>>> Thanks in advance >>>>> >>>>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: >>>>> >>>>>> De: Dragi?a Duri? >>>>>> Asunto: [M3devel] quake c_source, gcc -I directive >>>>>> Para: "m3devel" >>>>>> Fecha: s?bado, 24 de marzo, 2012 17:12 >>>>>> Anybody worked out an easy method >>>>>> resembling import_lib() to inform C compiler where to find >>>>>> include files in case it is not /usr/include? Like when I am >>>>>> using fink on a Mac, for example. >>>>>> >>>>>> TIA, >>>>>> dd >>>>>> >>>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Mar 26 04:40:15 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Mar 2012 02:40:15 +0000 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com>, <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org>, <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com>, <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org>, , Message-ID: We should support something like CFLAGS = CFLAGS & " -I/whatever" but we don't currently. ? SYSTEM_CC = SYSTEM_CC & " -I/whatever"almost works, but I don't believe generally does. - in the past, because SYSTEM_CC was readonly - currently because SYSTEM_CC is in some systems dynamically determined if/when any C code needs to be via configure_c_compiler (see cm3cfg.common) I don't know if Quake works this, way, but it'd be nice to be able to this: if defined(configure_c_compiler) previous_configure_c_compiler = configure_c_compiler else proc previous_configure_c_compiler() is end endproc configure_c_compiler() is previous_configure_c_compiler() SYSTEM_CC = SYSTEM_CC & " -I/whatever end more generally though, this should be somehow abstracted per-platform like SYSTEM_LIBS? Granted, it is kind of the same for all C compilers, the -I switch. The idea of a mult-dimensional abstraction per-library/include per-target per-host per-compiler (cc vs. gcc) is kind of annoying, esp. given that -I is pretty universial. I feel like I'm missing something though. We did have something like "CFLAGS". But I don't see it currently..I'm not looking in a smart way..maybe more later....maybe... - Jay > From: dragisha at m3w.org > Date: Sun, 25 Mar 2012 21:33:18 +0200 > To: antony.hosking at gmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quake c_source, gcc -I directive > > I tried obvious thing :) > > "/Users/dragisha/m3/libevent/src/m3makefile", line 9: quake runtime error: wrong number of parameters passed to procedure c_source (expected 1, received 2) > > > On Mar 25, 2012, at 3:49 PM, Antony Hosking wrote: > > > I am sure there is a way to do what you want with a simple one-liner in the m3makefile. > > Anyone remember? > > > > On Mar 25, 2012, at 3:46 AM, Dragi?a Duri? wrote: > > > >> Read through Darwin.common,Unix.common. No mention. > >> > >> SYSTEM_LIBS is for -L > >> > >> dd > >> > >> On Mar 25, 2012, at 3:39 AM, Antony Hosking wrote: > >> > >>> Can you not augment the standard system .h include paths as per the m3.cfg? > >>> > >>> On Mar 24, 2012, at 7:41 PM, Dragi?a Duri? wrote: > >>> > >>>> c_source("file") will compile file.c in same directory as m3makefile with that line is. And put object in ../$TARGET/file.o > >>>> > >>>> My question is, can I dd -I/sw/include so if my source has > >>>> > >>>> #include > >>>> > >>>> It will be found in /sw/include/event2/event.h > >>>> > >>>> Of course, /usr/include, for system .h's, should work at same time. > >>>> > >>>> dd > >>>> > >>>> > >>>> On Mar 25, 2012, at 12:37 AM, Daniel Alejandro Benavides D. wrote: > >>>> > >>>>> Hi all: > >>>>> I thought the c_source file had to be named in the same way your modula-3 sources (src), but for any other purposes like finding utilities inside your src tree src/D > >>>>> But if that's not the implementation you need but to link against I had to actually call the var outside the Modula-3 environment to override it in Modula-3 system linker. > >>>>> > >>>>> > >>>>> Thanks in advance > >>>>> > >>>>> --- El s?b, 24/3/12, Dragi?a Duri? escribi?: > >>>>> > >>>>>> De: Dragi?a Duri? > >>>>>> Asunto: [M3devel] quake c_source, gcc -I directive > >>>>>> Para: "m3devel" > >>>>>> Fecha: s?bado, 24 de marzo, 2012 17:12 > >>>>>> Anybody worked out an easy method > >>>>>> resembling import_lib() to inform C compiler where to find > >>>>>> include files in case it is not /usr/include? Like when I am > >>>>>> using fink on a Mac, for example. > >>>>>> > >>>>>> TIA, > >>>>>> dd > >>>>>> > >>>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Mar 26 09:04:29 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 26 Mar 2012 09:04:29 +0200 Subject: [M3devel] quake c_source, gcc -I directive In-Reply-To: References: <1332632269.84636.YahooMailClassic@web29703.mail.ird.yahoo.com>, <02B9E970-985F-4E6D-A443-7985C457F8DF@m3w.org>, <1AF005AC-DD5C-4797-94D7-63F8CBD605F8@gmail.com>, <5D03D2F9-D854-4D91-BB76-D4302F38AE73@m3w.org>, , Message-ID: <2DC7D00F-79E4-4FFD-BCF5-71139A9D563D@m3w.org> Works on AMD64_DARWIN, and that is what I neeed. Thank you! I think we need third argument to import_lib(). dd On Mar 26, 2012, at 4:40 AM, Jay K wrote: > We should support something like > CFLAGS = CFLAGS & " -I/whatever" > > > but we don't currently. ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: