From mika at async.caltech.edu Thu Nov 3 02:39:30 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Nov 2011 18:39:30 -0700 Subject: [M3devel] Trying to set up on AMD64_LINUX Message-ID: <20111103013930.50EAE1A2080@async.async.caltech.edu> Ran into an error I don't recognize, any ideas, anyone? myriam5% cm3 -commands --- building in AMD64_LINUX --- cd AMD64_LINUX ignoring ../src/m3overrides rm .M3SHIP rm .M3OVERRIDES inhale libm3core.m3x new source -> compiling ThreadPThreadC.c gcc -gstabs+ -m64 -fPIC -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/POSIX -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/PTHREAD -I../src/C/Common -I../src/float/C99 -I../src/time/POSIX -c ../src/thread/PTHREAD/ThreadPThreadC.c new "ThreadPThreadC.o" -> archiving libm3core.a rm libm3core.a fgrep m3gcdefs /ufs/arpa/mika/cm3/pkg/m3core/AMD64_LINUX/.M3EXPORTS 2>/dev/null >/dev/null rm libm3core.a rm libm3core.a.sa rm libm3core.so rm libm3core.so.5 rm libm3core.exp ar crus libm3core.a hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMac hine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.m o Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo gcc -gstabs+ -m64 -fPIC -Wl,-z,now -Wl,-z,origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/ufs/arpa/mika/cm3/bin/../lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RT Tipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMachine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo Poly Basis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.mo Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo -lm -pthread /usr/bin/ld: ThreadPThreadC.o: relocation R_X86_64_PC32 against `ThreadPThread__SignalHandler' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core Fatal Error: package build failed rm m3make.args cd .. % uname -a Linux noname5 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux From jay.krell at cornell.edu Thu Nov 3 03:16:18 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 02:16:18 +0000 Subject: [M3devel] Trying to set up on AMD64_LINUX In-Reply-To: <20111103013930.50EAE1A2080@async.async.caltech.edu> References: <20111103013930.50EAE1A2080@async.async.caltech.edu> Message-ID: Possible a gcc bug. Possibly related to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 Possible fix is to stop using attribte(hidden) and such, but really, they are good things. I can poke around later maybe. I think AMD64_LINUX is a relatively popular platform here. Try with a newer gcc/ld? Try removing this: #if __GNUC__ >= 4 #pragma GCC visibility push(hidden) #endif in ThreadPThreadC.c. if that works, let's keep it, but move stuff around. Like, maybe move void SignalHandler(int signo, siginfo_t *info, void *context); above it, or put another decoration on that. - Jay > To: m3devel at elegosoft.com > Date: Wed, 2 Nov 2011 18:39:30 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] Trying to set up on AMD64_LINUX > > Ran into an error I don't recognize, any ideas, anyone? > > myriam5% cm3 -commands > --- building in AMD64_LINUX --- > > cd AMD64_LINUX > ignoring ../src/m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale libm3core.m3x > > new source -> compiling ThreadPThreadC.c > gcc -gstabs+ -m64 -fPIC -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/POSIX -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/PTHREAD -I../src/C/Common -I../src/float/C99 -I../src/time/POSIX -c ../src/thread/PTHREAD/ThreadPThreadC.c > > new "ThreadPThreadC.o" -> archiving libm3core.a > rm libm3core.a > fgrep m3gcdefs /ufs/arpa/mika/cm3/pkg/m3core/AMD64_LINUX/.M3EXPORTS 2>/dev/null >/dev/null > rm libm3core.a > rm libm3core.a.sa > rm libm3core.so > rm libm3core.so.5 > rm libm3core.exp > ar crus libm3core.a hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMac > hine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo > DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.m > o Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo > gcc -gstabs+ -m64 -fPIC -Wl,-z,now -Wl,-z,origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/ufs/arpa/mika/cm3/bin/../lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RT > Tipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMachine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io > M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo Poly > Basis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.mo Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo -lm -pthread > /usr/bin/ld: ThreadPThreadC.o: relocation R_X86_64_PC32 against `ThreadPThread__SignalHandler' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3core > Fatal Error: package build failed > rm m3make.args > cd .. > > % uname -a > Linux noname5 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 07:24:54 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 06:24:54 +0000 Subject: [M3devel] Target.i3/Target.m3 reduction? Message-ID: There is fairly little target-dependent-ness in our system, aside from the gcc code. I would like to reduce it. There are a few forms: There is dependency on word size. This I don't see removing any time soon, given that the front end does layout of records and computation of field offsets. There is dependency on jumpbuf size. We mostly know how to remove this, but have failed so far. The generated code should use alloca for the locals. (and even then, longer term, don't use setjmp/longjmp). We have these big arrays of targets, esp. in m3middle/src/Target.i3: PA32_HPUX, PA64_HPUX, PPC32_OPENBSD, PPC64_DARWIN, PPC_DARWIN, PPC_LINUX, ... Many of the dependencies are really per architecture or per kernel, not per architecture x kernel combination. So this almost-cross product seems dumb. Suggestions? There is dependency on endianness. This is what I'm really focusing on. I think this only matters for interop with C bitfields. We have no C bitfields in our system now. And the frontend and backend I think have to agree...oh, nevermind, I don't see that in parse.c > Aligned_procedures Just be safe and assume this is always false? Or it is a nice optimization on the common x86/AMD64 platforms? > First_readable_addr Just hardcode this as 4K? Instead of the slight optimization of setting it to 8K for SPARC? > Allow_packed_byte_aligned The safe value here is false. We set it to true only for x86/AMD64. I think true is probably safe for all architectures but older Alphas. ? > Setjmp This has the same value on platforms except VMS. We can maybe provide a portably-named wrapper? Maybe not, since this function is kind of special. I have to go.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Nov 3 07:50:21 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Nov 2011 23:50:21 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20111103055141.DE9FECC8A7@birch.elegosoft.com> References: <20111103055141.DE9FECC8A7@birch.elegosoft.com> Message-ID: <20111103065021.EC1341A2080@async.async.caltech.edu> Hi Jay, This does seem to have fixed the problem, as far as I can tell. Thanks as always. Mika Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 11/11/03 06:51:41 > >Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c > >Log message: > declare SignalHandler before pragma GCC visibility push(hidden), see if > it helps From jay.krell at cornell.edu Thu Nov 3 08:09:07 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 07:09:07 +0000 Subject: [M3devel] new CVS commit output? Message-ID: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v <-- Alpha64.common new revision: 1.4; previous revision: 1.3 cDebug turned on... $VAR1 = [ 'cm3/m3-sys/cminstall/src/config-no-install', 'ALPHA_LINUX', 'ALPHA_OPENBSD', 'Alpha64.common' ]; module - cm3 dir - path - files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX ALPHA_OPENBSD Alpha64.common id - 21684 Searching for log file index... found log file at 0.21684, now writing tmp files. Checking current dir against last dir. Current directory cm3/m3-sys/cminstall/src/config-no-install is last directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all commits done. format_lists(): cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. ARGV -> -d -m m3commit at elegosoft.com -s -M cm3 -f ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 08:28:01 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 07:28:01 +0000 Subject: [M3devel] CM3 on IA64? In-Reply-To: <1317708354.1319.2.camel@zx6000.hecnet.eu> References: <4E8A34A9.6070704@wickensonline.co.uk>, , <1317699760.16995.YahooMailClassic@web29708.mail.ird.yahoo.com>, , <1317708354.1319.2.camel@zx6000.hecnet.eu> Message-ID: 1) I didn't get the error you got, but I fixed it anyway. 2) Please try this: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-IA64_LINUX-d5.9.0-20111103.tgz Which is the output of ./boot1.py IA64_LINUX. 3) Can you help me update this code: #elif defined(__linux) #if defined(__i386) context->uc_mcontext.gregs[REG_EIP] #elif defined(__amd64) context->uc_mcontext.gregs[REG_RIP] #elif defined(__powerpc) context->uc_mcontext.uc_regs->gregs[PT_NIP] #elif defined(__arm__) context->uc_mcontext.arm_pc #elif defined(__alpha__) context->uc_mcontext.sc_pc #else #error unknown __linux target #endif You will hit this #error with that .tar.gz. or I guess please give me access to the machine, thank you. My ssh public key is attached. (I think it is time I generate new keys though..) Thank you, - Jay > Subject: RE: [M3devel] CM3 on IA64? > From: mark at wickensonline.co.uk > To: jay.krell at cornell.edu > CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com > Date: Tue, 4 Oct 2011 07:05:54 +0100 > > Jay, > > If you do ever feel like tackling the problem again I can give you > access to Alpha and IA64 OpenVMS boxes as required. > > Regards, Mark. > > On Tue, 2011-10-04 at 05:24 +0000, Jay K wrote: > > VMS is a more difficult port..except that it is approaching Posix > > these days. > > I had it far along, for Alpha. My system wasn't up to date wrt Posix > > features. > > Linux on IA64 should be very easy. > > > > - Jay > > > > > > > Date: Tue, 4 Oct 2011 04:42:40 +0100 > > > From: dabenavidesd at yahoo.es > > > To: m3devel at elegosoft.com; mark at wickensonline.co.uk > > > Subject: Re: [M3devel] CM3 on IA64? > > > > > > Hi all: > > > you might find surprisingly more clients for the same platform: > > > http://unix.derkeiler.com/Newsgroups/comp.os.vms/2004-03/0130.html > > > > > > In the news of Ken Olsen's obituary, they mentioned how DEC was not > > about micros, then it would explain some interest on the language in > > that, besides not too many Mainframes machine are build this days, I > > would certainly interested in to take a look about what it can do > > about in OpenVMS (a native port of threads for instance, could be > > interesting). I don't know any Mainframe OSes, would run this days, > > Linux. If OpenVMS has the sources for purchase, would they license > > freely to construct replicas, etc? The post sounds it may take it up > > to that point if people gets involved. Obviously IA64 is just another > > beast but who cares that matter right now. > > > OK, maybe there is that Modula-3 has its kind of EE, would you > > matter to ask what is that? > > > http://www.computer.org/portal/web/csdl/doi/10.1109/4236.991448 > > > > > > It could be that of DoD Generic Trusted Intermediaries GTI, which > > was constructed for among others Trusted Solaris and alike is related, > > But,the thing is who is using it right now or used it. > > > doi:10.1080/10658989709342533 > > > > > > Thanks in advance > > > > > > --- El lun, 3/10/11, Mark Wickens > > escribi?: > > > > > > > De: Mark Wickens > > > > Asunto: [M3devel] CM3 on IA64? > > > > Para: m3devel at elegosoft.com > > > > Fecha: lunes, 3 de octubre, 2011 17:18 > > > > Hi guys, > > > > > > > > Has anyone attempted a port of CM3 to Itanium > > > > architecture? > > > > I've recently installed gentoo on my ZX6000 and it's all > > > > running very nicely. > > > > My thoughts turned to what would be involved in getting > > > > Modula-3 running. > > > > > > > > Kind regards, Mark. > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: id_dsa.pub Type: application/octet-stream Size: 600 bytes Desc: not available URL: From michael.anderson at elegosoft.com Thu Nov 3 10:52:47 2011 From: michael.anderson at elegosoft.com (Michael Anderson) Date: Thu, 03 Nov 2011 10:52:47 +0100 Subject: [M3devel] new CVS commit output? In-Reply-To: References: Message-ID: <4EB2646F.6090704@elegosoft.com> Indeed. There is some extra debugging output to help me figure out a problem with path parsing in the cvs log/mailer scripts. I'll have that fixed up shortly. Sorry for the console spam. Mike Am 11/3/11 8:09 AM, schrieb Jay K: > > > > /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v > <-- Alpha64.common > new revision: 1.4; previous revision: 1.3 > cDebug turned on... > $VAR1 = [ > 'cm3/m3-sys/cminstall/src/config-no-install', > 'ALPHA_LINUX', > 'ALPHA_OPENBSD', > 'Alpha64.common' > ]; > > module - cm3 > dir - > path - > files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX > ALPHA_OPENBSD Alpha64.common > id - 21684 > Searching for log file index... found log file at 0.21684, now writing > tmp files. > Checking current dir against last dir. > Current directory cm3/m3-sys/cminstall/src/config-no-install is last > directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all > commits done. > format_lists(): > cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common > format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; > files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. > ARGV -> > -d > -m > m3commit at elegosoft.com > -s > -M > cm3 > -f > > > > ? > > - Jay -- Michael Anderson IT Services& Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 17:57:05 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 16:57:05 +0000 Subject: [M3devel] new CVS commit output? In-Reply-To: <4EB2646F.6090704@elegosoft.com> References: , <4EB2646F.6090704@elegosoft.com> Message-ID: No problem. I'm just making sure it is expected. - Jay Date: Thu, 3 Nov 2011 10:52:47 +0100 From: michael.anderson at elegosoft.com To: m3devel at elegosoft.com Subject: Re: [M3devel] new CVS commit output? Indeed. There is some extra debugging output to help me figure out a problem with path parsing in the cvs log/mailer scripts. I'll have that fixed up shortly. Sorry for the console spam. Mike Am 11/3/11 8:09 AM, schrieb Jay K: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v <-- Alpha64.common new revision: 1.4; previous revision: 1.3 cDebug turned on... $VAR1 = [ 'cm3/m3-sys/cminstall/src/config-no-install', 'ALPHA_LINUX', 'ALPHA_OPENBSD', 'Alpha64.common' ]; module - cm3 dir - path - files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX ALPHA_OPENBSD Alpha64.common id - 21684 Searching for log file index... found log file at 0.21684, now writing tmp files. Checking current dir against last dir. Current directory cm3/m3-sys/cminstall/src/config-no-install is last directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all commits done. format_lists(): cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. ARGV -> -d -m m3commit at elegosoft.com -s -M cm3 -f ? - Jay -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Nov 4 08:30:10 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 04 Nov 2011 00:30:10 -0700 Subject: [M3devel] adding new target? Message-ID: <20111104073010.D20E21A2080@async.async.caltech.edu> Hi Jay, I know you have mentioned before that it's now "easy" to add a new target. I would like to add a target that is already mostly there, I think. The one I want is mipsel-linux. This is to run on an Asus RT-N16 router running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors and 128 MB of DRAM. First before you read this email, are there any instructions for what I'm trying to do anywhere, beyond your emails? I am using boot1.py as you suggested. What I did was the following (guesses all along): made a cm3.cfg which I called MIPSEL_LINUX and put in m3-sys/cminstall/src/config-no-install: :::: readonly TARGET = "MIPSEL_LINUX" % code generation target readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler SYSTEM_ASM = "as" % Assembler m3back_m32 = "" % -m32 not allowed include("MIPSEL.common") include("Linux.common") :::: where MIPSEL.common contains: :::: readonly TARGET_ARCH = "MIPS" readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } :::: Now I don't really know which of these strings are just arbitrary strings that I'm defining here and which of them have to match other things (and if so, what they have to match). In any case I'm doing something wrong because I do (on a FreeBSD4 machine)... ./boot1.py MIPSEL_LINUX which runs for a bit and eventually degenerates to gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log gmake: `libcpp.a' is up to date. cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log gmake: `s-modes' is up to date. gmake: `insn-config.h' is up to date. gmake: Nothing to be done for `m3cg'. --- building in FreeBSD4 --- new source -> compiling RTHooks.i3 ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic new source -> compiling RT0.i3 ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RT0.ic new source -> compiling RuntimeError.i3 ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 ... Mika From dabenavidesd at yahoo.es Fri Nov 4 17:28:29 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 16:28:29 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: <20111104073010.D20E21A2080@async.async.caltech.edu> Message-ID: <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> Hi all: Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false This is a must in terms of addresanility, besides others like the endianess or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: http://www.fortunecity.com/skyscraper/motorola/22/resume.htm ). At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: http://www.youtube.com/watch?v=WUfvvFD5tAA. I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): http://users.crocker.com/~hudson/hudson.html Thanks in advance --- El vie, 4/11/11, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: [M3devel] adding new target? > Para: m3devel at elegosoft.com > Fecha: viernes, 4 de noviembre, 2011 02:30 > Hi Jay, > > I know you have mentioned before that it's now "easy" to > add a new target. > I would like to add a target that is already mostly there, > I think. > The one I want is mipsel-linux. This is to run on an > Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz > MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any > instructions for what > I'm trying to do anywhere, beyond your emails? I am > using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { > "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { > "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just > arbitrary > strings that I'm defining here and which of them have to > match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a > FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** > illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal > error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > > From jay.krell at cornell.edu Fri Nov 4 17:35:06 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 16:35:06 +0000 Subject: [M3devel] adding new target? In-Reply-To: <20111104073010.D20E21A2080@async.async.caltech.edu> References: <20111104073010.D20E21A2080@async.async.caltech.edu> Message-ID: Please put "32" in the name of the target? That's just preference/taste, not a requirement. > cd ../FreeBSD4-I386_FREEBSD We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. I realize that is also confusing. But it is how you can transition from the old target names to the new ones. > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 And then later on we probably confused .ic/.mc files for assembly source or vice versa. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. grep -r -i linux m3makefile *quake* or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? - Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 18:07:52 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 17:07:52 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: Message-ID: <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: in that case, it isn't the LINUXLIBC6 a better name for these targets (at least in Debian 3.0 or so), I mean, not necessarily embedded speaking. And then what does it mean that is not more or less upward "compatibility". Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] adding new target? Para: "Mika Nystrom" , "m3devel" Fecha: viernes, 4 de noviembre, 2011 11:35 ?Please put "32" in the name of the target? That's just preference/taste, not a requirement. ? > cd ../FreeBSD4-I386_FREEBSD ?We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. ?I realize that is also confusing. But it is how you can transition from the old target names to the new ones. ? > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5? ? And then later on we probably confused .ic/.mc files for assembly source or vice versa.? ?See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. ?We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. ?grep -r -i linux m3makefile *quake*? or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? ?- Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 4 18:36:58 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 17:36:58 +0000 Subject: [M3devel] adding new target? In-Reply-To: <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> References: , <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: Eh, maybe. Maybe MIPS32EL_LINUXLIBC6. I'm really not familiar with the versions. I think prior to 6 wasn't glibc and >=6 is glibc, and it probably hasn't gone to 7. In which case, no. This is also a confusing name, because almost nobody knows what "libc6" implies. Consider that most users weren't around before. And even I'm not sure what it means. I do believe the kernel version is relevant here also. That 2.4 never had decent pthreads, never had NPTL. But Linux certainly has had pthreads since long before 2.6/NPTL. - Jay Date: Fri, 4 Nov 2011 17:07:52 +0000 From: dabenavidesd at yahoo.es To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] adding new target? Hi all: in that case, it isn't the LINUXLIBC6 a better name for these targets (at least in Debian 3.0 or so), I mean, not necessarily embedded speaking. And then what does it mean that is not more or less upward "compatibility". Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] adding new target? Para: "Mika Nystrom" , "m3devel" Fecha: viernes, 4 de noviembre, 2011 11:35 Please put "32" in the name of the target? That's just preference/taste, not a requirement. > cd ../FreeBSD4-I386_FREEBSD We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. I realize that is also confusing. But it is how you can transition from the old target names to the new ones. > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 And then later on we probably confused .ic/.mc files for assembly source or vice versa. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. grep -r -i linux m3makefile *quake* or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? - Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 4 18:39:19 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 17:39:19 +0000 Subject: [M3devel] adding new target? In-Reply-To: <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> References: <20111104073010.D20E21A2080@async.async.caltech.edu>, <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> Message-ID: > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. - Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 19:08:29 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 18:08:29 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: Message-ID: <1320430109.66209.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: well, but nonetheless, like first DEC pdp-10 didn't have those: http://www.xkl.com/darkstar.html Even today I doubt modern pdp-10 would have it or not, maybe I guess. In retrospective you sort of fell like you could build your own OS for those big machines, even now, why wouldn't one think the same way. I think they even created paging hardware and basically the same sort of handling would depend on the OS itself as well to handle it (they had ported some Unix from AT&T and BSD of historic value but I don't know even a Linux distro that runs on it or something like that, well maybe some emulator). http://en.wikipedia.org/wiki/SIMH#Digital_Equipment_Corporation The interest on this stuff is the packet fields and BITS types of Modula-3, wouldn't be nice to have those on a recent hardware implementations? But then we would need to address the INTEGER issues, and etc (p.d they have ported gcc to there, so this is fact possible: http://gcc.gnu.org/ml/gcc/2008-04/msg00516.html ) Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] adding new target? Para: dabenavidesd at yahoo.es, "m3devel" , "Mika Nystrom" Fecha: viernes, 4 de noviembre, 2011 12:39 > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. ?- Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 23:31:52 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 22:31:52 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: <1320430109.66209.YahooMailClassic@web29707.mail.ird.yahoo.com> Message-ID: <1320445912.67026.YahooMailClassic@web29713.mail.ird.yahoo.com> Hi all: in fact there are even new hardware hacks for that as well, someones in practice: http://homepage.mac.com/dgcx/pdp10x/ http://www.freak-search.com/en/thread/3102486/its_starting_to_be_a_pdp-10 Besides that I think the Thread implementation on SRC Modula-3 used to depend on an instruction that the Pdp-10 could execute so we can afford to compete one of those beasts with modern ones to see real and emulated performance, if one such DECiestis interested: http://www.webservertalk.com/archive154-2006-5-1505344.html I would host on of those, but how much power does it consume, very angry machine, although important steps for history of Computation, maybe in a virtual museum :) https://www.msu.edu/~mrr/mycomp/cdc6000/cdc_emulators.htm Thanks in advance --- El vie, 4/11/11, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] adding new target? Para: "m3devel" , "Mika Nystrom" , "Jay K" Fecha: viernes, 4 de noviembre, 2011 13:08 Hi all: well, but nonetheless, like first DEC pdp-10 didn't have those: http://www.xkl.com/darkstar.html Even today I doubt modern pdp-10 would have it or not, maybe I guess. In retrospective you sort of fell like you could build your own OS for those big machines, even now, why wouldn't one think the same way. I think they even created paging hardware and basically the same sort of handling would depend on the OS itself as well to handle it (they had ported some Unix from AT&T and BSD of historic value but I don't know even a Linux distro that runs on it or something like that, well maybe some emulator). http://en.wikipedia.org/wiki/SIMH#Digital_Equipment_Corporation The interest on this stuff is the packet fields and BITS types of Modula-3, wouldn't be nice to have those on a recent hardware implementations? But then we would need to address the INTEGER issues, and etc (p.d they have ported gcc to there, so this is fact possible: http://gcc.gnu.org/ml/gcc/2008-04/msg00516.html ) Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] adding new target? Para: dabenavidesd at yahoo.es, "m3devel" , "Mika Nystrom" Fecha: viernes, 4 de noviembre, 2011 12:39 > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. ?- Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Tue Nov 15 23:44:17 2011 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 15 Nov 2011 22:44:17 +0000 Subject: [M3devel] m2tom3 Message-ID: <4EC2EB41.6010203@wickensonline.co.uk> Guys, I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz I attempted to compile it using cm3, but I get an unknown interface: msw at x60:~/m2tom3/m2tom3/src$ cm3 --- building in ../LINUXLIBC6 --- unsupported m3_option value: "-O" new source -> compiling Standard.m3 "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) 1 error encountered compilation failed => not building program "m2tom3" Fatal Error: package build failed Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. Regards, Makr. From rcolebur at SCIRES.COM Wed Nov 16 00:17:33 2011 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 15 Nov 2011 18:17:33 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: Mark: I seem to recall that "TextF" was for "Text Friends" and that it was removed after Critical Mass changed the underlying TEXT representation to deal with the new wide character sets. Here is a link that describes it a bit more: http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes So, you will need to recode any operations that used the old TextF interface. If you want, I'll look around and see if I have an old copy of TextF laying around that you can review to see what code you will need to implement. I don't think it will be too much work. Let me know if you need it. Perhaps someone else on this thread has already done something along these lines. Regards, Randy Coleburn -----Original Message----- From: Mark Wickens [mailto:mark at wickensonline.co.uk] Sent: Tuesday, November 15, 2011 5:44 PM To: m3devel Subject: [M3devel] m2tom3 Guys, I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz I attempted to compile it using cm3, but I get an unknown interface: msw at x60:~/m2tom3/m2tom3/src$ cm3 --- building in ../LINUXLIBC6 --- unsupported m3_option value: "-O" new source -> compiling Standard.m3 "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) 1 error encountered compilation failed => not building program "m2tom3" Fatal Error: package build failed Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. Regards, Makr. From mika at async.caltech.edu Wed Nov 16 00:24:57 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 15 Nov 2011 15:24:57 -0800 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <20111115232457.78E2C1A205B@async.async.caltech.edu> What I would do is: 1. delete IMPORT TextF 2. see what breaks, figure out the intent of the code, recode it using Text 3. check in the result to the CM3 repository so no one has to do it again! Mika Mark Wickens writes: >Guys, > >I found the m2tom3 translation utility here: >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >I attempted to compile it using cm3, but I get an unknown interface: > >msw at x60:~/m2tom3/m2tom3/src$ cm3 >--- building in ../LINUXLIBC6 --- > >unsupported m3_option value: "-O" >new source -> compiling Standard.m3 >"../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >1 error encountered >compilation failed => not building program "m2tom3" >Fatal Error: package build failed > > >Has anyone heard of interface TextF? Alternatively, is there a port of >this utility to cm3? > >I recently uncovered a machine-readable copy of my degree final year >project, a Meta Assembler, written in Modula-2, and wondered if I could >get it to compile using the utility to work with Modula-3. > >Regards, > >Makr. From dabenavidesd at yahoo.es Wed Nov 16 01:22:31 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 00:22:31 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111115232457.78E2C1A205B@async.async.caltech.edu> Message-ID: <1321402951.28257.YahooMailClassic@web29714.mail.ird.yahoo.com> Hi all: yeah my fault, but as I recall although I could compile this years ago, the main issue is that it didn't even work to feed the file to compile or so failed in therefore the first character was read. So it never worked for real for me. My best bet would export a SUN Unix syscall interface (since it tailored the SUN Modula-2 library) spec like Sphinx in SPIN OS so an export of it for every Modula-3 program understands itself right (yeah it coudl take the years spent from when I compiled until today, or so). If I were to start a new project perhaps would start making Unix legacy and updated replacements. The other approach perhaps the most indicated is just to wrap C on SPIN code to make it user level server. This could make the thing (inf act there is FreeBSD server already there just miss several calls, but nonetheless is something there). BTW, I don' know which platform this compiler used to work, so the main point would be emulate the real sys calls, since they just emulated in Sun OS and Solaris, nothing more. This has a potential utility for another project that depends on this m2tom3 tool. Thanks in advance --- El mar, 15/11/11, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 18:24 > What I would do is: > > 1. delete IMPORT TextF > 2. see what breaks, figure out the intent of the code, > recode it using Text > 3. check in the result to the CM3 repository so no one has > to do it again! > > Mika > > Mark Wickens writes: > >Guys, > > > >I found the m2tom3 translation utility here: > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > >I attempted to compile it using cm3, but I get an > unknown interface: > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > >--- building in ../LINUXLIBC6 --- > > > >unsupported m3_option value: "-O" > >new source -> compiling Standard.m3 > >"../src/Analyzer/Standard.m3", line 25: unable to find > interface (TextF) > >1 error encountered > >compilation failed => not building program "m2tom3" > >Fatal Error: package build failed > > > > > >Has anyone heard of interface TextF? Alternatively, is > there a port of > >this utility to cm3? > > > >I recently uncovered a machine-readable copy of my > degree final year > >project, a Meta Assembler, written in Modula-2, and > wondered if I could > >get it to compile using the utility to work with > Modula-3. > > > >Regards, > > > >Makr. > From dabenavidesd at yahoo.es Wed Nov 16 02:22:35 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 01:22:35 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321402951.28257.YahooMailClassic@web29714.mail.ird.yahoo.com> Message-ID: <1321406555.89220.YahooMailClassic@web29720.mail.ird.yahoo.com> Hi all: just forget that, it's done, the only thing we need is the SUN Modula-2 compilers, and that's all folks :) http://homepage.mac.com/dr2chase/resume.html How enough hard this men worked but how much good fellows they were (I can't see anything like this today in industry). Thanks in advance --- El mar, 15/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 19:22 > Hi all: > yeah my fault, but as I recall although I could compile > this years ago, the main issue is that it didn't even work > to feed the file to compile or so failed in therefore the > first character was read. So it never worked for real for > me. > My best bet would export a SUN Unix syscall interface > (since it tailored the SUN Modula-2 library) spec like > Sphinx in SPIN OS so an export of it for every Modula-3 > program understands itself right (yeah it coudl take the > years spent from when I compiled until today, or so). > If I were to start a new project perhaps would start making > Unix legacy and updated replacements. > The other approach perhaps the most indicated is just to > wrap C on SPIN code to make it user level server. This could > make the thing (inf act there is FreeBSD server already > there just miss several calls, but nonetheless is something > there). > BTW, I don' know which platform this compiler used to work, > so the main point would be emulate the real sys calls, since > they just emulated in Sun OS and Solaris, nothing more. This > has a potential utility for another project that depends on > this m2tom3 tool. > Thanks in advance > > --- El mar, 15/11/11, Mika Nystrom > escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 18:24 > > What I would do is: > > > > 1. delete IMPORT TextF > > 2. see what breaks, figure out the intent of the > code, > > recode it using Text > > 3. check in the result to the CM3 repository so no one > has > > to do it again! > > > > Mika > > > > Mark Wickens writes: > > >Guys, > > > > > >I found the m2tom3 translation utility here: > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > >I attempted to compile it using cm3, but I get an > > unknown interface: > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > >--- building in ../LINUXLIBC6 --- > > > > > >unsupported m3_option value: "-O" > > >new source -> compiling Standard.m3 > > >"../src/Analyzer/Standard.m3", line 25: unable to > find > > interface (TextF) > > >1 error encountered > > >compilation failed => not building program > "m2tom3" > > >Fatal Error: package build failed > > > > > > > > >Has anyone heard of interface TextF? > Alternatively, is > > there a port of > > >this utility to cm3? > > > > > >I recently uncovered a machine-readable copy of > my > > degree final year > > >project, a Meta Assembler, written in Modula-2, > and > > wondered if I could > > >get it to compile using the utility to work with > > Modula-3. > > > > > >Regards, > > > > > >Makr. > > > From dabenavidesd at yahoo.es Wed Nov 16 20:56:59 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 19:56:59 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321406555.89220.YahooMailClassic@web29720.mail.ird.yahoo.com> Message-ID: <1321473419.50950.YahooMailClassic@web29720.mail.ird.yahoo.com> Hi all: I think this is the way to get out of this "moral-technical" issue with the Unix interfaces, so get back to the old style (of course not brutal cross product), though we could that for the sake of further compatibility (it should be transparent ideally, like an Universal VM), but compiled natively (DEC SRC had the Ultrix VAX API as well, so for vax, openVMS you could do that surely). And at the end just EXPORT Unix.System() or UnixV, UnixVI, etc and that's all. OK, let me know, thanks in advance --- El mar, 15/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 20:22 > Hi all: > just forget that, it's done, the only thing we need is the > SUN Modula-2 compilers, and that's all folks :) > http://homepage.mac.com/dr2chase/resume.html > > How enough hard this men worked but how much good fellows > they were (I can't see anything like this today in > industry). > > Thanks in advance > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > escribi?: > > > De: Daniel Alejandro Benavides D. > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" , > "Mika Nystrom" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 19:22 > > Hi all: > > yeah my fault, but as I recall although I could > compile > > this years ago, the main issue is that it didn't even > work > > to feed the file to compile or so failed in therefore > the > > first character was read. So it never worked for real > for > > me. > > My best bet would export a SUN Unix syscall interface > > (since it tailored the SUN Modula-2 library) spec > like > > Sphinx in SPIN OS so an export of it for every > Modula-3 > > program understands itself right (yeah it coudl take > the > > years spent from when I compiled until today, or so). > > If I were to start a new project perhaps would start > making > > Unix legacy and updated replacements. > > The other approach perhaps the most indicated is just > to > > wrap C on SPIN code to make it user level server. This > could > > make the thing (inf act there is FreeBSD server > already > > there just miss several calls, but nonetheless is > something > > there). > > BTW, I don' know which platform this compiler used to > work, > > so the main point would be emulate the real sys calls, > since > > they just emulated in Sun OS and Solaris, nothing > more. This > > has a potential utility for another project that > depends on > > this m2tom3 tool. > > Thanks in advance > > > > --- El mar, 15/11/11, Mika Nystrom > > escribi?: > > > > > De: Mika Nystrom > > > Asunto: Re: [M3devel] m2tom3 > > > Para: "Mark Wickens" > > > CC: m3devel at elegosoft.com > > > Fecha: martes, 15 de noviembre, 2011 18:24 > > > What I would do is: > > > > > > 1. delete IMPORT TextF > > > 2. see what breaks, figure out the intent of the > > code, > > > recode it using Text > > > 3. check in the result to the CM3 repository so > no one > > has > > > to do it again! > > > > > > Mika > > > > > > Mark Wickens writes: > > > >Guys, > > > > > > > >I found the m2tom3 translation utility here: > > > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > >I attempted to compile it using cm3, but I > get an > > > unknown interface: > > > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > >--- building in ../LINUXLIBC6 --- > > > > > > > >unsupported m3_option value: "-O" > > > >new source -> compiling Standard.m3 > > > >"../src/Analyzer/Standard.m3", line 25: > unable to > > find > > > interface (TextF) > > > >1 error encountered > > > >compilation failed => not building > program > > "m2tom3" > > > >Fatal Error: package build failed > > > > > > > > > > > >Has anyone heard of interface TextF? > > Alternatively, is > > > there a port of > > > >this utility to cm3? > > > > > > > >I recently uncovered a machine-readable copy > of > > my > > > degree final year > > > >project, a Meta Assembler, written in > Modula-2, > > and > > > wondered if I could > > > >get it to compile using the utility to work > with > > > Modula-3. > > > > > > > >Regards, > > > > > > > >Makr. > > > > > > From dabenavidesd at yahoo.es Thu Nov 17 04:36:56 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 17 Nov 2011 03:36:56 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321473419.50950.YahooMailClassic@web29720.mail.ird.yahoo.com> Message-ID: <1321501016.42602.YahooMailClassic@web29709.mail.ird.yahoo.com> Hi all: and I see this: http://labs.oracle.com/forest/COM.Sun.Labs.Forest.doc.see_97.paper_pdf.pdf indicated that it was possible to either compile and cross-assemble or compile and run over its DEC-SRC Microkernel VMS code, at least at user-level. Anyway, the main thing here is that this cross-ports like SOLGnu or Darwin are actually possible to run in one compilation and two code generations. That is better functionality or at least I guess so for those platforms as well. Of course the idea would be run in SPIN, but in some cases like SPINE it can run actually NT386GNU and NT386 or for instance run in a LAN a NT_ALPHA_GNU (SPINE) and ALPHA_SPIN code almost instantly (like if it would an user-level server) alternatively or somehow a crazy thing like that in IX86 likewise setting. Thanks in advance --- El mi?, 16/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: mi?rcoles, 16 de noviembre, 2011 14:56 > Hi all: > I think this is the way to get out of this > "moral-technical" issue with the Unix interfaces, so get > back to the old style (of course not brutal cross product), > though we could that for the sake of further compatibility > (it should be transparent ideally, like an Universal VM), > but compiled natively (DEC SRC had the Ultrix VAX API as > well, so for vax, openVMS you could do that surely). > And at the end just EXPORT Unix.System() or UnixV, UnixVI, > etc and that's all. > OK, let me know, thanks in advance > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > escribi?: > > > De: Daniel Alejandro Benavides D. > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" , > "Mika Nystrom" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 20:22 > > Hi all: > > just forget that, it's done, the only thing we need is > the > > SUN Modula-2 compilers, and that's all folks :) > > http://homepage.mac.com/dr2chase/resume.html > > > > How enough hard this men worked but how much good > fellows > > they were (I can't see anything like this today in > > industry). > > > > Thanks in advance > > > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > > > escribi?: > > > > > De: Daniel Alejandro Benavides D. > > > Asunto: Re: [M3devel] m2tom3 > > > Para: "Mark Wickens" , > > "Mika Nystrom" > > > CC: m3devel at elegosoft.com > > > Fecha: martes, 15 de noviembre, 2011 19:22 > > > Hi all: > > > yeah my fault, but as I recall although I could > > compile > > > this years ago, the main issue is that it didn't > even > > work > > > to feed the file to compile or so failed in > therefore > > the > > > first character was read. So it never worked for > real > > for > > > me. > > > My best bet would export a SUN Unix syscall > interface > > > (since it tailored the SUN Modula-2 library) > spec > > like > > > Sphinx in SPIN OS so an export of it for every > > Modula-3 > > > program understands itself right (yeah it coudl > take > > the > > > years spent from when I compiled until today, or > so). > > > If I were to start a new project perhaps would > start > > making > > > Unix legacy and updated replacements. > > > The other approach perhaps the most indicated is > just > > to > > > wrap C on SPIN code to make it user level server. > This > > could > > > make the thing (inf act there is FreeBSD server > > already > > > there just miss several calls, but nonetheless > is > > something > > > there). > > > BTW, I don' know which platform this compiler > used to > > work, > > > so the main point would be emulate the real sys > calls, > > since > > > they just emulated in Sun OS and Solaris, > nothing > > more. This > > > has a potential utility for another project that > > depends on > > > this m2tom3 tool. > > > Thanks in advance > > > > > > --- El mar, 15/11/11, Mika Nystrom > > > escribi?: > > > > > > > De: Mika Nystrom > > > > Asunto: Re: [M3devel] m2tom3 > > > > Para: "Mark Wickens" > > > > CC: m3devel at elegosoft.com > > > > Fecha: martes, 15 de noviembre, 2011 18:24 > > > > What I would do is: > > > > > > > > 1. delete IMPORT TextF > > > > 2. see what breaks, figure out the intent of > the > > > code, > > > > recode it using Text > > > > 3. check in the result to the CM3 repository > so > > no one > > > has > > > > to do it again! > > > > > > > > Mika > > > > > > > > Mark Wickens writes: > > > > >Guys, > > > > > > > > > >I found the m2tom3 translation utility > here: > > > > > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > > >I attempted to compile it using cm3, but > I > > get an > > > > unknown interface: > > > > > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > > >--- building in ../LINUXLIBC6 --- > > > > > > > > > >unsupported m3_option value: "-O" > > > > >new source -> compiling Standard.m3 > > > > >"../src/Analyzer/Standard.m3", line 25: > > unable to > > > find > > > > interface (TextF) > > > > >1 error encountered > > > > >compilation failed => not building > > program > > > "m2tom3" > > > > >Fatal Error: package build failed > > > > > > > > > > > > > > >Has anyone heard of interface TextF? > > > Alternatively, is > > > > there a port of > > > > >this utility to cm3? > > > > > > > > > >I recently uncovered a machine-readable > copy > > of > > > my > > > > degree final year > > > > >project, a Meta Assembler, written in > > Modula-2, > > > and > > > > wondered if I could > > > > >get it to compile using the utility to > work > > with > > > > Modula-3. > > > > > > > > > >Regards, > > > > > > > > > >Makr. > > > > > > > > > > From rodney_bates at lcwb.coop Thu Nov 17 17:29:04 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Nov 2011 10:29:04 -0600 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <4EC53650.6070206@lcwb.coop> I have used m2tom3 successfully a couple of times in the (distant) past. There are a few places where the languages are different enough that you get either unidiomatic or unworkable translations. As I recall, the method of returning a function result will require some hand cleanup, and variant records, if you have them, will just be flattened, rather than converted to an object type hierarchy. Nevertheless, it will save a *lot* of tedious editing of mundane syntactic nits. TextF exposes PM3's internal representation of TEXT values, which is altogether different from that of CM3, so you will not be able to use it unless you use PM3. I am sure it is in the PM3 distribution at Elego, and I know I have copies around. By now, PM3 has probably suffered some bitrot, so installing it might take some work. I have an installation around on a machine that has not been powered up for a few months, but probably works. I probably also have a compiled executable for m2tom3 on LINUXLIBC6 that might run on a machine of that type. I could provide a copy of that, if you want to see if you can do it without putting in a lot of work. Or maybe I could just run it for you a few times. On 11/15/2011 04:44 PM, Mark Wickens wrote: > Guys, > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > I attempted to compile it using cm3, but I get an unknown interface: > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > --- building in ../LINUXLIBC6 --- > > unsupported m3_option value: "-O" > new source -> compiling Standard.m3 > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > 1 error encountered > compilation failed => not building program "m2tom3" > Fatal Error: package build failed > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > Regards, > > Makr. > > From rodney_bates at lcwb.coop Thu Nov 17 18:09:49 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Nov 2011 11:09:49 -0600 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <4EC53FDD.2040301@lcwb.coop> I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. The result is attached. It compiled and linked on AMD64_LINUX, and executed enough to give the help text and to translate a tiny bit of Modula-2 code. I'm biting my tongue on why it was coded this way in the first place. On 11/15/2011 04:44 PM, Mark Wickens wrote: > Guys, > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > I attempted to compile it using cm3, but I get an unknown interface: > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > --- building in ../LINUXLIBC6 --- > > unsupported m3_option value: "-O" > new source -> compiling Standard.m3 > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > 1 error encountered > compilation failed => not building program "m2tom3" > Fatal Error: package build failed > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > Regards, > > Makr. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Standard.m3 URL: From jay.krell at cornell.edu Thu Nov 17 18:57:53 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Nov 2011 17:57:53 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <4EC53FDD.2040301@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk>,<4EC53FDD.2040301@lcwb.coop> Message-ID: Commit the initial version, and then the revisions, to the cm3 repository? - Jay > Date: Thu, 17 Nov 2011 11:09:49 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m2tom3 > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > The result is attached. > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > and to translate a tiny bit of Modula-2 code. > > I'm biting my tongue on why it was coded this way in the first place. > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > Guys, > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > I attempted to compile it using cm3, but I get an unknown interface: > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > --- building in ../LINUXLIBC6 --- > > > > unsupported m3_option value: "-O" > > new source -> compiling Standard.m3 > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > 1 error encountered > > compilation failed => not building program "m2tom3" > > Fatal Error: package build failed > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > Regards, > > > > Makr. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Thu Nov 17 19:40:37 2011 From: mark at wickensonline.co.uk (Mark Wickens) Date: Thu, 17 Nov 2011 18:40:37 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <4EC53FDD.2040301@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC55525.8010904@wickensonline.co.uk> On 17/11/11 17:09, Rodney M. Bates wrote: > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > by eliminating IMPORT TextF and changing 4 places from the form > TextVariable[j] > to Text.GetChar(TextVariable,j). This is file > m2tom3/src/Analyzer/Standard,m3. > The result is attached. > > It compiled and linked on AMD64_LINUX, and executed enough to give the > help text > and to translate a tiny bit of Modula-2 code. > > I'm biting my tongue on why it was coded this way in the first place. > > On 11/15/2011 04:44 PM, Mark Wickens wrote: >> Guys, >> >> I found the m2tom3 translation utility here: >> http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >> I attempted to compile it using cm3, but I get an unknown interface: >> >> msw at x60:~/m2tom3/m2tom3/src$ cm3 >> --- building in ../LINUXLIBC6 --- >> >> unsupported m3_option value: "-O" >> new source -> compiling Standard.m3 >> "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >> 1 error encountered >> compilation failed => not building program "m2tom3" >> Fatal Error: package build failed >> >> >> Has anyone heard of interface TextF? Alternatively, is there a port >> of this utility to cm3? >> >> I recently uncovered a machine-readable copy of my degree final year >> project, a Meta Assembler, written in Modula-2, and wondered if I >> could get it to compile using the utility to work with Modula-3. >> >> Regards, >> >> Makr. >> >> Thanks Rodney, My M3 skills aren't up to much - I'll give it a whirl later. Regards, Mark. From michael.anderson at elegosoft.com Fri Nov 18 10:31:31 2011 From: michael.anderson at elegosoft.com (Michael Anderson) Date: Fri, 18 Nov 2011 10:31:31 +0100 Subject: [M3devel] [elego Server Maintenance] Friday, 18.11.2011 20:30 CET Message-ID: <4EC625F3.6030100@elegosoft.com> Hello, On Friday, November 18 at 8:30 PM CET, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services& Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Fri Nov 18 18:11:04 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:11:04 -0600 Subject: [M3devel] m2tom3 Standard.m3, second try. In-Reply-To: <4EC56C22.4040005@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> <4EC56C22.4040005@wickensonline.co.uk> Message-ID: <4EC691A8.7080200@lcwb.coop> Opps, sorry. That was the unmodified version. I seem to have two different subdirectories with m3tom3 in them. Try this one. On 11/17/2011 02:18 PM, Mark Wickens wrote: > On 17/11/11 17:09, Rodney M. Bates wrote: >> I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 >> by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] >> to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. >> The result is attached. >> >> It compiled and linked on AMD64_LINUX, and executed enough to give the help text >> and to translate a tiny bit of Modula-2 code. >> >> I'm biting my tongue on why it was coded this way in the first place. >> >> On 11/15/2011 04:44 PM, Mark Wickens wrote: >>> Guys, >>> >>> I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >>> I attempted to compile it using cm3, but I get an unknown interface: >>> >>> msw at x60:~/m2tom3/m2tom3/src$ cm3 >>> --- building in ../LINUXLIBC6 --- >>> >>> unsupported m3_option value: "-O" >>> new source -> compiling Standard.m3 >>> "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >>> 1 error encountered >>> compilation failed => not building program "m2tom3" >>> Fatal Error: package build failed >>> >>> >>> Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? >>> >>> I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. >>> >>> Regards, >>> >>> Makr. >>> >>> > Hi Rodney, is the version of Standard.m3 attached to your email the one you modified? > I can still see an import of TextF. > > Thanks for the help, > > Mark. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Standard.m3 URL: From rodney_bates at lcwb.coop Fri Nov 18 18:24:28 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:24:28 -0600 Subject: [M3devel] m2tom3 In-Reply-To: References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC694CC.1070004@lcwb.coop> Olaf, is there a place in the elego-hosted repositories I can put this? I don't find it already present in my local copy of cm3. Can I create a new subdirectory, say in cm3/m3-tools? On this topic, I have a few library packages that might be useful to somebody someday. Would Elegosoft be interested in hosting them? On 11/17/2011 11:57 AM, Jay K wrote: > Commit the initial version, and then the revisions, to the cm3 repository? > > - Jay > > Date: Thu, 17 Nov 2011 11:09:49 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m2tom3 > > > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > > The result is attached. > > > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > > and to translate a tiny bit of Modula-2 code. > > > > I'm biting my tongue on why it was coded this way in the first place. > > > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > > Guys, > > > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > I attempted to compile it using cm3, but I get an unknown interface: > > > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > --- building in ../LINUXLIBC6 --- > > > > > > unsupported m3_option value: "-O" > > > new source -> compiling Standard.m3 > > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > > 1 error encountered > > > compilation failed => not building program "m2tom3" > > > Fatal Error: package build failed > > > > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > > > Regards, > > > > > > Makr. > > > > > > From rodney_bates at lcwb.coop Fri Nov 18 18:25:22 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:25:22 -0600 Subject: [M3devel] m2tom3 In-Reply-To: References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC69502.4050800@lcwb.coop> Olaf, is there a place in the elego-hosted repositories I can put this? I don't find it already present in my local copy of cm3. Can I create a new subdirectory, say in cm3/m3-tools or cm3/tools? On this topic, I have a few library packages that might be useful to somebody someday. Would Elegosoft be interested in hosting them? On 11/17/2011 11:57 AM, Jay K wrote: > Commit the initial version, and then the revisions, to the cm3 repository? > > - Jay > > Date: Thu, 17 Nov 2011 11:09:49 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m2tom3 > > > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > > The result is attached. > > > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > > and to translate a tiny bit of Modula-2 code. > > > > I'm biting my tongue on why it was coded this way in the first place. > > > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > > Guys, > > > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > I attempted to compile it using cm3, but I get an unknown interface: > > > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > --- building in ../LINUXLIBC6 --- > > > > > > unsupported m3_option value: "-O" > > > new source -> compiling Standard.m3 > > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > > 1 error encountered > > > compilation failed => not building program "m2tom3" > > > Fatal Error: package build failed > > > > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > > > Regards, > > > > > > Makr. > > > > > > From wagner at elegosoft.com Wed Nov 23 10:53:18 2011 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Nov 2011 10:53:18 +0100 Subject: [M3devel] m2tom3 In-Reply-To: <4EC694CC.1070004@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> <4EC694CC.1070004@lcwb.coop> Message-ID: <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> Hi Rodney, sorry for answering so late. Quoting "Rodney M. Bates" : > Olaf, is there a place in the elego-hosted repositories I can put this? > I don't find it already present in my local copy of cm3. > Can I create a new subdirectory, say in cm3/m3-tools? Of course, just cvs-add it. Please make sure that it compiles though. > On this topic, I have a few library packages that might be useful > to somebody someday. Would Elegosoft be interested in hosting them? As long as you don't upload gigabytes of M3 source code (let us know of that in advance :-), please feel free to add and share any library that you think may be useful for others. We should probably add some documentation for them and re-run and ship the m3tohtml results to the web server, but that can be done later. Thanks for your contributions, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Nov 23 16:18:34 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 23 Nov 2011 10:18:34 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> <4EC694CC.1070004@lcwb.coop> <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> Message-ID: <20111123151833.GA13397@topoi.pooq.com> On Wed, Nov 23, 2011 at 10:53:18AM +0100, Olaf Wagner wrote: > Hi Rodney, > > sorry for answering so late. > > Quoting "Rodney M. Bates" : > > >Olaf, is there a place in the elego-hosted repositories I can put this? > >I don't find it already present in my local copy of cm3. > >Can I create a new subdirectory, say in cm3/m3-tools? > > Of course, just cvs-add it. Please make sure that it compiles though. > > >On this topic, I have a few library packages that might be useful > >to somebody someday. Would Elegosoft be interested in hosting them? > > As long as you don't upload gigabytes of M3 source code (let us know > of that in advance :-), please feel free to add and share any library > that you think may be useful for others. > > We should probably add some documentation for them and re-run and > ship the m3tohtml results to the web server, but that can be done > later. > > Thanks for your contributions, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 Would it be useful to dual-licence new code under the LGPL(2 or later) on the remote chance that other parts of Modula 3 might someday also be so licenced. Or, for that matter, that someone might want to translate it to another language, by hand or otherwise? That would then be a derived work, also LGPL-able. Just trying to reduce future barriers to interoperation. -- hendrik > From dabenavidesd at yahoo.es Wed Nov 23 17:08:55 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 16:08:55 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111123151833.GA13397@topoi.pooq.com> Message-ID: <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> Hi all: if one were to rework MODULES INTERFACEs IMHO yes, would be useful, anyway, that should make no harm other's code (when appropitely veryfied at elast in ESC/Modula-3), when developing enough of libm3. A Short term could be m3core RT INTERFACES as they developed as a standard Modula-3, which they declare "free to use and implement". I however don't know about other's companies codes, since they could offer just that for their purposes, but that's less central of the issue. For instance linking other FOSS could be approved by that change in order to break down even further dependence. Inthe other side, DEC-SRC licence is pretty liberal, so it could be thought as GPL-compatible, which means that the same license is able to cope with the FOSS definitions, even that of FSF. Thanks in advance --- El mi?, 23/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 23 de noviembre, 2011 10:18 > On Wed, Nov 23, 2011 at 10:53:18AM > +0100, Olaf Wagner wrote: > > Hi Rodney, > > > > sorry for answering so late. > > > > Quoting "Rodney M. Bates" : > > > > >Olaf, is there a place in the elego-hosted > repositories I can put this? > > >I don't find it already present in my local copy > of cm3. > > >Can I create a new subdirectory, say in > cm3/m3-tools? > > > > Of course, just cvs-add it. Please make sure that it > compiles though. > > > > >On this topic, I have a few library packages that > might be useful > > >to somebody someday. Would Elegosoft be > interested in hosting them? > > > > As long as you don't upload gigabytes of M3 source > code (let us know > > of that in advance :-), please feel free to add and > share any library > > that you think may be useful for others. > > > > We should probably add some documentation for them and > re-run and > > ship the m3tohtml results to the web server, but that > can be done > > later. > > > > Thanks for your contributions, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > Would it be useful to dual-licence new code under the > LGPL(2 or later) > on the remote chance that other parts of Modula 3 might > someday also be > so licenced. Or, for that matter, that someone might > want to translate > it to another language, by hand or otherwise? That > would then be a > derived work, also LGPL-able. > > Just trying to reduce future barriers to interoperation. > > -- hendrik > > > > From vintagecoder at aol.com Wed Nov 23 17:19:57 2011 From: vintagecoder at aol.com (vintagecoder at aol.com) Date: Wed, 23 Nov 2011 16:19:57 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <20111123151833.GA13397@topoi.pooq.com> Message-ID: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> > Would it be useful to dual-licence new code under the LGPL(2 or later) on > the remote chance that other parts of Modula 3 might someday also be so > licenced. Or, for that matter, that someone might want to translate it > to another language, by hand or otherwise? That would then be a derived > work, also LGPL-able. The Critical Mass license is perfectly fine. What is the sick fascination with GPL? Why can't people just leave things alone and not try to force other people to live according to their rules. LGPL is just a slippery slope. > Just trying to reduce future barriers to interoperation. Really? The GPL never reduced any barriers. It is *all about* barriers. You truly want to reduce future barriers? Then public-domain your code or use a BSD or MIT license. Or just use the Critical Mass license and stop trying to turn everything into Linux. From dabenavidesd at yahoo.es Wed Nov 23 17:51:13 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 16:51:13 +0000 (GMT) Subject: [M3devel] m2tom3 Message-ID: <1322067073.72825.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: In fact the bottom line is how we can create an environment enough capable of hosting several languages or at least enough easy to develop cross compilers from Pascal, Modula-2 and Simula like languages for the benefit of those interested in porting legacy applications in a Modern of the day SOTA programming system with high performance and still easy deployment, which is hard to find this days on other platforms even to older or new systems ranging from CDC and Algol systems to embedded platforms of the and a Code generation Interface for C-based languages, like Fail-Safe (IDL, see: http://www.yonezaki.cs.titech.ac.jp/Workshop/isss2003/slides/Suenaga.pdf ), or something like for SPIN's Cove, which is the best languages that could be safe enough to share RT structures with Modula-3, etc, else it has no point to re-implement those UNSAFE interfaces with C instead of Modula-3 code IMHO. Also as a way to allow further development in even that languages as well if so as needed. Thanks in advance --- El mi?, 23/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com, "Hendrik Boom" > Fecha: mi?rcoles, 23 de noviembre, 2011 11:08 > Hi all: > if one were to rework MODULES INTERFACEs IMHO yes, would be > useful, anyway, that should make no harm other's code (when > appropitely veryfied at elast in ESC/Modula-3), when > developing enough of libm3. A Short term could be > m3core RT INTERFACES as they developed as a standard > Modula-3, which they declare "free to use and implement". I > however don't know about other's companies codes, since they > could offer just that for their purposes, but that's less > central of the issue. For instance linking other FOSS could > be approved by that change in order to break down even > further dependence. > Inthe other side, DEC-SRC licence is pretty liberal, so it > could be thought as GPL-compatible, which means that > the same license is able to cope with the FOSS definitions, > even that of FSF. > Thanks in advance > > --- El mi?, 23/11/11, Hendrik Boom > escribi?: > > > De: Hendrik Boom > > Asunto: Re: [M3devel] m2tom3 > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 23 de noviembre, 2011 10:18 > > On Wed, Nov 23, 2011 at 10:53:18AM > > +0100, Olaf Wagner wrote: > > > Hi Rodney, > > > > > > sorry for answering so late. > > > > > > Quoting "Rodney M. Bates" : > > > > > > >Olaf, is there a place in the elego-hosted > > repositories I can put this? > > > >I don't find it already present in my local > copy > > of cm3. > > > >Can I create a new subdirectory, say in > > cm3/m3-tools? > > > > > > Of course, just cvs-add it. Please make sure that > it > > compiles though. > > > > > > >On this topic, I have a few library packages > that > > might be useful > > > >to somebody someday. Would Elegosoft > be > > interested in hosting them? > > > > > > As long as you don't upload gigabytes of M3 > source > > code (let us know > > > of that in advance :-), please feel free to add > and > > share any library > > > that you think may be useful for others. > > > > > > We should probably add some documentation for > them and > > re-run and > > > ship the m3tohtml results to the web server, but > that > > can be done > > > later. > > > > > > Thanks for your contributions, > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 > 2345 > > 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > > USt-IdNr: DE163214194 > > > > Would it be useful to dual-licence new code under the > > LGPL(2 or later) > > on the remote chance that other parts of Modula 3 > might > > someday also be > > so licenced. Or, for that matter, that someone > might > > want to translate > > it to another language, by hand or otherwise? > That > > would then be a > > derived work, also LGPL-able. > > > > Just trying to reduce future barriers to > interoperation. > > > > -- hendrik > > > > > > > > From dabenavidesd at yahoo.es Wed Nov 23 18:16:50 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 17:16:50 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> Message-ID: <1322068610.69293.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: a perfect example of compatibility is the DEC-SRC SRCCollector Interface inter with GNU C Boehm's Collector compatible interface: http://opensource.apple.com/source/gcc/gcc-5493/boehm-gc/doc/README.macros And that happened a long time before [1] DEC-SRC closing so they knew at least that it could be possible to compile (and inferring types)/link to interchange both collectors (fully capable and enough compatible interfaces to make GC-safe in both DEC-SRC Modula-3 and GNU C languages, where is the counterexample for what you say) flawlessly say in any environment. Thanks in advance [1] H.-J. Boehm and Z. Shao, ?Inferring Type Maps during Garbage Collection,? IN OOPSLA ?93 WORKSHOP ON MEMORY MANAGEMENT AND GARBAGE COLLECTION, 1993. --- El mi?, 23/11/11, vintagecoder at aol.com escribi?: > De: vintagecoder at aol.com > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 23 de noviembre, 2011 11:19 > > Would it be useful to > dual-licence new code under the LGPL(2 or later) on > > the remote chance that other parts of Modula 3 might > someday also be so > > licenced. Or, for that matter, that someone > might want to translate it > > to another language, by hand or otherwise? That > would then be a derived > > work, also LGPL-able. > > The Critical Mass license is perfectly fine. What is the > sick fascination > with GPL? Why can't people just leave things alone and not > try to force > other people to live according to their rules. LGPL is just > a slippery > slope. > > > Just trying to reduce future barriers to > interoperation. > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > You truly want to reduce future barriers? Then > public-domain your code or > use a BSD or MIT license. Or just use the Critical Mass > license and stop > trying to turn everything into Linux. > From dabenavidesd at yahoo.es Thu Nov 24 22:30:35 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 24 Nov 2011 21:30:35 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1322068610.69293.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <1322170235.80764.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: in fact we need to address surely in a near future since xds Development Environment system has DEC-SRC Modula-3 infrastructure for Modula-2, Oberon-2 mixable Modules project compatibility: http://www.excelsior-usa.com/xds.html This could of big help for a lot of good tools that have applied for Modula-3 type system R&D. So instead of thinking in license mess, we would be thinking in language mixing. About that they are thinking in releasing the source codes, perhaps, if Elego folks would show interest we could bring some of their tools. The bottom line of this is we would have same capabilities like CM3-IDE ability to navigate sources, so to have source to source transformations seemingly navigation and code generations capabilities (like for C in XDS system). I suggest we can make something for that, given the same structure of compilers, of course there is a lot of work, but we could do it, you are so great programmers. Thanks in advance --- El mi?, 23/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com, vintagecoder at aol.com > Fecha: mi?rcoles, 23 de noviembre, 2011 12:16 > Hi all: > a perfect example of compatibility is the DEC-SRC > SRCCollector Interface inter with GNU C Boehm's Collector > compatible interface: > http://opensource.apple.com/source/gcc/gcc-5493/boehm-gc/doc/README.macros > > And that happened a long time before [1] DEC-SRC closing so > they knew at least that it could be possible to compile (and > inferring types)/link to interchange both collectors (fully > capable and enough compatible interfaces to make GC-safe in > both DEC-SRC Modula-3 and GNU C languages, where is the > counterexample for what you say) flawlessly say in any > environment. > > Thanks in advance > > [1] H.-J. Boehm and Z. Shao, ?Inferring Type Maps during > Garbage Collection,? IN OOPSLA ?93 WORKSHOP ON MEMORY > MANAGEMENT AND GARBAGE COLLECTION, 1993. > > > --- El mi?, 23/11/11, vintagecoder at aol.com > > escribi?: > > > De: vintagecoder at aol.com > > > Asunto: Re: [M3devel] m2tom3 > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 23 de noviembre, 2011 11:19 > > > Would it be useful to > > dual-licence new code under the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might > > someday also be so > > > licenced. Or, for that matter, that > someone > > might want to translate it > > > to another language, by hand or otherwise? > That > > would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the > > sick fascination > > with GPL? Why can't people just leave things alone and > not > > try to force > > other people to live according to their rules. LGPL is > just > > a slippery > > slope. > > > > > Just trying to reduce future barriers to > > interoperation. > > > > Really? The GPL never reduced any barriers. It is > *all > > about* barriers. > > > > You truly want to reduce future barriers? Then > > public-domain your code or > > use a BSD or MIT license. Or just use the Critical > Mass > > license and stop > > trying to turn everything into Linux. > > > From hendrik at topoi.pooq.com Thu Nov 24 23:13:43 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 24 Nov 2011 17:13:43 -0500 Subject: [M3devel] licences, again In-Reply-To: <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> References: <20111123151833.GA13397@topoi.pooq.com> <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> Message-ID: <20111124221343.GA13709@topoi.pooq.com> On Wed, Nov 23, 2011 at 04:08:55PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > if one were to rework MODULES INTERFACEs IMHO yes, would be useful, anyway, that should make no harm other's code (when appropitely veryfied at elast in ESC/Modula-3), when developing enough of libm3. A Short term could be m3core RT INTERFACES as they developed as a standard Modula-3, which they declare "free to use and implement". I however don't know about other's companies codes, since they could offer just that for their purposes, but that's less central of the issue. For instance linking other FOSS could be approved by that change in order to break down even further dependence. I can't say I really understand this paragraph. > Inthe other side, DEC-SRC licence is pretty liberal, so it could be thought as GPL-compatible, which means that the same license is able to cope with the FOSS definitions, even that of FSF. Certainly, I'd like it to be compatible with GPL. But I've been told that the FSF considers the DEC-SRC licence incompatible with the GPL. -- hendrik From hendrik at topoi.pooq.com Thu Nov 24 23:24:20 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 24 Nov 2011 17:24:20 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> References: <20111123151833.GA13397@topoi.pooq.com> <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> Message-ID: <20111124222420.GB13709@topoi.pooq.com> On Wed, Nov 23, 2011 at 04:19:57PM +0000, vintagecoder at aol.com wrote: > > Would it be useful to dual-licence new code under the LGPL(2 or later) on > > the remote chance that other parts of Modula 3 might someday also be so > > licenced. Or, for that matter, that someone might want to translate it > > to another language, by hand or otherwise? That would then be a derived > > work, also LGPL-able. > > The Critical Mass license is perfectly fine. What is the sick fascination > with GPL? Just that a lot of free software *is* released inder the GPL, and it would be convenient to be compatible. > Why can't people just leave things alone and not try to force > other people to live according to their rules. LGPL is just a slippery > slope. > > > Just trying to reduce future barriers to interoperation. > > Really? The GPL never reduced any barriers. It is *all about* barriers. It's about limiting one's freedom to limit others' freedom. And that is a barrrier, right. But the way to bypass the barrier is to release code under multiple licences, the GPL or LGPL together with whatever licence you prefer. Potential users can then choose whichever licence suits them. > > You truly want to reduce future barriers? Then public-domain your code or > use a BSD or MIT license. Those licences would do, yes. I suspect they're compatible with both the SRC licence (which the CM licence is based on) and GPL (but can anyone confirm that?). > Or just use the Critical Mass license and stop > trying to turn everything into Linux. It's actually on Windows that it's a particular problem. It's usual to distribute binaries there. Most potential Windows users don't have their own software development tools and can only use prelinked binaries. It's on Posix systems such as Linux that we have less of a problem, because they usually come with adequate development tools. -- hendrik From dabenavidesd at yahoo.es Fri Nov 25 00:46:32 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 24 Nov 2011 23:46:32 +0000 (GMT) Subject: [M3devel] licences, again In-Reply-To: <20111124221343.GA13709@topoi.pooq.com> Message-ID: <1322178392.49293.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi: thanks for the message. Again I meant, that surely we could work out this by recording all libm3 libraries suddenly and then make the all library LGPL (as suggested by Richard Stallman) or whatever the Folks want. So, I guess the best approach is given that the DEC-SRC report declares Modula-3 free use and implement as stated there: ftp://ftp.hpl.hp.com/pub/dec/SRC/research-reports/SRC-052.pdf "The right to implement or use the Modula-3 language is unrestricted" Therefore as some libm3 INTERFACEs are part of that Language Definition as some in m3core (which should be all in m3core or in libm3 but not in both IMHO) we could code MODULEs an license them in again whatever folks want (or even on several license but carefully, as DEC-SRC did: ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/copyright.html ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/commercial.html ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/non_commercial.html But I think they are all exactly the same document, so clearly there is was ? outdated and error-prone documentation (the tittle is wrong anyway in the commercial.html file), BTW Elego has a broken link: http://modula3.elegosoft.com/cm3/doc/reference/license.html in http://modula3.elegosoft.com/rsrc/digital-license.html Finally the history tells they "recreated" the Commercial license, I guess this was related to the fact that Pine Creek Software left Modula-3 Business somewhere in the 1993 or so as I recall. So that could be the effect of that. Anyway the new license docs seem like '94 so would be good to see what is the status of the current license, and that's the reason RMS said this was not good for FSF, since I think they were talking about this before '94 Naturally someone should be able to tell what the heck is this all about, first non-commercial license, the first commercial one and the newest. There is a tool the did in DEC-SRC, we could have to look for that: http://www.lim.nl/monitor/hector.html p 22 see: http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-92.pdf Thanks in advance --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] licences, again > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:13 > On Wed, Nov 23, 2011 at 04:08:55PM > +0000, Daniel Alejandro Benavides D. wrote: > > Hi all: > > if one were to rework MODULES INTERFACEs IMHO yes, > would be useful, anyway, that should make no harm other's > code (when appropitely veryfied at elast in ESC/Modula-3), > when developing enough of libm3. A Short term could be > m3core RT INTERFACES as they developed as a standard > Modula-3, which they declare "free to use and implement". I > however don't know about other's companies codes, since they > could offer just that for their purposes, but that's less > central of the issue. For instance linking other FOSS could > be approved by that change in order to break down even > further dependence. > > I can't say I really understand this paragraph. > > > Inthe other side, DEC-SRC licence is pretty liberal, > so it could be thought as GPL-compatible, which means > that the same license is able to cope with the FOSS > definitions, even that of FSF. > > Certainly, I'd like it to be compatible with GPL. > > But I've been told that the FSF considers the DEC-SRC > licence > incompatible with the GPL. > > -- hendrik > From dabenavidesd at yahoo.es Fri Nov 25 01:41:33 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 25 Nov 2011 00:41:33 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <1322181693.78177.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi all: I knew that for instance OpenWatcom or Watcom by that time had written a piece of code with resemblance of Modula-3 I guess NT implementation so I guess as I recall I saw the DEC-SRC Copyright license for commercial product there but I can't get into it, I would need time to dig their sources if there is any still that has that license, see: http://en.wikipedia.org/wiki/Open_Watcom See dates match exactly before 1994 license change http://research.microsoft.com/pubs/64242/implementingcvs.pdf There is controversy with Debian and Fedora legal teams, which I don't care more than OpenWatcom compiler had Modula-3 based code in their time, so if they got that before 94 (in 93) I guess this is the the way to go to understand the legalese, or say that DEC granted its license in other licenses which is sort of the idea in the GPL case even if it is not adjusted to it. IF FSF wants to ask for their license I don't see any reason for preventing asking that for. Thanks in advance --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:24 > On Wed, Nov 23, 2011 at 04:19:57PM > +0000, vintagecoder at aol.com > wrote: > > > Would it be useful to dual-licence new code under > the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might someday also be so > > > licenced. Or, for that matter, that someone > might want to translate it > > > to another language, by hand or otherwise? > That would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the sick fascination > > with GPL? > > Just that a lot of free software *is* released inder the > GPL, and it > would be convenient to be compatible. > > > Why can't people just leave things alone and not try > to force > > other people to live according to their rules. LGPL is > just a slippery > > slope. > > > > > Just trying to reduce future barriers to > interoperation. > > > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > It's about limiting one's freedom to limit others' > freedom. And that > is a barrrier, right. But the way to bypass the > barrier is to release > code under multiple licences, the GPL or LGPL together with > whatever > licence you prefer. Potential users can then choose > whichever licence > suits them. > > > > You truly want to reduce future barriers? Then > public-domain your code or > > use a BSD or MIT license. > > Those licences would do, yes. I suspect they're > compatible with both > the SRC licence (which the CM licence is based on) and GPL > (but can > anyone confirm that?). > > > Or just use the Critical Mass license and stop > > trying to turn everything into Linux. > > It's actually on Windows that it's a particular > problem. It's usual to > distribute binaries there. Most potential Windows > users don't have > their own software development tools and can only use > prelinked > binaries. > > It's on Posix systems such as Linux that we have less of a > problem, > because they usually come with adequate development tools. > > -- hendrik > > From dabenavidesd at yahoo.es Fri Nov 25 04:28:22 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 25 Nov 2011 03:28:22 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <1322191702.57301.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi all: in fact i think MS has the anti-free software parade creating cells of users in Universities, because they see how dramatically Java ad many others like GNU and Linux and all projects are just sweeping them (sorry if the words sound strong but what it feels is like that) as much they sweep in the industry, well most of times, say 90%. That's why they tell the history of their concern of Copyrights, which somehow is a FSF concern too if that was the case with the Modula-3 gnu based tools I see (here MS uses the naive terms Author's rights), so the idea behind this is they feel "bad" if the copy proprietary software is shared and so the rest is history, bu the main threat could not been even that but the actual fact that in the "Cloud", or virtual networked environments we will need to find a way of obviating or bypass this regulations, since is useless there, sicne it will be bypassed anyway, even if you go today to a video site store you get music that would be paid for in some parts of the world but still free in others which is point-less anyway if so, but that depends in where you are going to access those things but if everything is virtual it senseless, since would one make virtual systsems in a X country prohibit if they serve in Y country, obiously not I guess! I remember in fact a tale about virtual system trying to control that you can't give a web page to another individual, which sorts of feels bad, you know, you can't show anybody a thing is you pay for (If I can find the reference I will share it). The antithesis was developed long before an Image-based Electronic Library [1], in AT&T Labs, where they associated for Copyright compliance efforts with Copyright Clearance Center CCC to ask the authors that didn't agree to allow photocopying their paper texts, to ask them directly if they might do so for their project. I imagine a similar thing for the new tools on the Virtual Networked environments, where you share code directly on the net and so get involved in those efforts is something that is making proprietary users to feel threatened by that if so, for instance we could really make a Copyright clearance of Modula-3 sources (but implicitly telling FSF that we can share with them if they want to share code with us as well, which they could need who knows as I believe there are network packages here and there for Linux, etc. in Modula-3) so FSF feels happier and might want to ask the sources in other licenses which I believe is what concerns them they would do easier. That's my little idea of the new computation era "issues". Thanks in advance. [1] G. A. Story, L. O?Gorman, D. Fox, L. L. Schaper, and H. V. Jagadish, ?The RightPages image-based electronic library for alerting and browsing,? Computer, vol. 25, pp. 17-26, Sep. 1992. --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:24 > On Wed, Nov 23, 2011 at 04:19:57PM > +0000, vintagecoder at aol.com > wrote: > > > Would it be useful to dual-licence new code under > the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might someday also be so > > > licenced. Or, for that matter, that someone > might want to translate it > > > to another language, by hand or otherwise? > That would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the sick fascination > > with GPL? > > Just that a lot of free software *is* released inder the > GPL, and it > would be convenient to be compatible. > > > Why can't people just leave things alone and not try > to force > > other people to live according to their rules. LGPL is > just a slippery > > slope. > > > > > Just trying to reduce future barriers to > interoperation. > > > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > It's about limiting one's freedom to limit others' > freedom. And that > is a barrrier, right. But the way to bypass the > barrier is to release > code under multiple licences, the GPL or LGPL together with > whatever > licence you prefer. Potential users can then choose > whichever licence > suits them. > > > > You truly want to reduce future barriers? Then > public-domain your code or > > use a BSD or MIT license. > > Those licences would do, yes. I suspect they're > compatible with both > the SRC licence (which the CM licence is based on) and GPL > (but can > anyone confirm that?). > > > Or just use the Critical Mass license and stop > > trying to turn everything into Linux. > > It's actually on Windows that it's a particular > problem. It's usual to > distribute binaries there. Most potential Windows > users don't have > their own software development tools and can only use > prelinked > binaries. > > It's on Posix systems such as Linux that we have less of a > problem, > because they usually come with adequate development tools. > > -- hendrik > > From vintagecoder at aol.com Sat Nov 26 19:35:45 2011 From: vintagecoder at aol.com (vintagecoder at aol.com) Date: Sat, 26 Nov 2011 18:35:45 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <201111261835.pAQIZofL030035@ims-m12.mx.aol.com> >> The Critical Mass license is perfectly fine. What is the sick fascination >> with GPL? >Just that a lot of free software *is* released inder the GPL, and it >would be convenient to be compatible. A lot of /Linux/ software has been infected by GPL's viral forcible open source license. BSD and MIT licenses existed before GPL, they are truly /free/ and open source licenses, and they are also compatible with the GPL (for me that compatibility is worth nothing). If you use the GPL you will contaminate the original DEC license and people who would have contributed or included your software in situations where BSD and MIT licenses are common and accepted but who don't like GPL (OpenBSD for a notable example) will have problems with it. I personally have a problem with it. I was very pleased to find CM3 and the SRC license and I would be very dissapointed if it was contaminated by the GPL in the future. If you are going for freedom, there are a few good choices and none of them are GPL. I cannot any reason other than politics for adding the GPL to a preexisting product. I sincerely hope elegosoft avoids this! >> Why can't people just leave things alone and not try to force >> other people to live according to their rules. LGPL is just a slippery >> slope. > > Just trying to reduce future barriers to interoperation. > >> Really? The GPL never reduced any barriers. It is *all about* barriers. > It's about limiting one's freedom to limit others' freedom. And that is > a barrrier, right. But the way to bypass the barrier is to release code > under multiple licences, the GPL or LGPL together with whatever licence > you prefer. Potential users can then choose whichever licence suits > them. Mixing and matching licenses doesn't help because the GPL adds restrictions that aren't present in true free open source licenses. If you feel it necessary to license, what is the reason? Do you want to maintain ownership and foster community participation? Then use BSD or MIT licenses which are compatible with any open source license. Do you want to make a political statement and jump on a bandwagon over a cliff to the point where many big operations won't touch your product for fear of having to expose their code? Choose GPL. The GPL is incompatible with most open source licenses because it is not free, it adds restrictions that other licenses don't have. I read recently MINIX had said they are attempting to build commercial support and demand for their OS and they found the BSD license a significant help in doing that. They said many potential customers object to the GPL. From a standpoint of true freedom /and/ possible commercial success the BSD and MIT style licenses seem so obviously superior to a viral forcible open source license, I just can't see why anybody would choose the GPL except for purely political reasons. It's self destructive. >> You truly want to reduce future barriers? Then public-domain your code or >> use a BSD or MIT license. >Those licences would do, yes. I suspect they're compatible with both >the SRC licence (which the CM licence is based on) and GPL (but can >anyone confirm that?). Yes, I can confirm they're compatible from GPL's standpoint. I don't know about the DEC/SRC license. >> Or just use the Critical Mass license and stop >> trying to turn everything into Linux. > It's actually on Windows that it's a particular problem. It's usual to > distribute binaries there. Most potential Windows users don't have their > own software development tools and can only use prelinked binaries. I understand Windows users are mostly stuck with prebuilt applications. I don't understand what licensing considerations have to do with that. If you use the SRC license does that have any effect on the executables? If so, how will adding code with other licenses whether BSD, MIT, or even GPL make anything simpler or change anything? If the CM3 runtime is included in the SRC license then that is the low bar, that is, you will only be able to add restrictions to it, not remove any. If the runtime is not included then I think it would be extremely unwise to encumber it any further. I feel it would be unwise to encumber it any further in any case. From dabenavidesd at yahoo.es Sat Nov 26 20:42:30 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 26 Nov 2011 19:42:30 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <201111261835.pAQIZofL030035@ims-m12.mx.aol.com> Message-ID: <1322336550.58691.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: If anyone working a networking tool uses a _DEC_ license why would you suggest asking they to release it in a different license if only that makes work with another package to _DEC_. Is their obligation to release that, according to the original license you can not ask them to release their sources in that other license so, unless you clear the _DEC_ license then it makes no sense to do that later, in that view it's necessary to ask them more than one time. So that makes the all idea of sub license not clever at all which is what others did. The point is whatever package uses Modula-3 will need that license. Does this feel fair? I say if you have another license (and commercial house like Pine Creek Software, or others as well), makes sense since you can actually give away your software or not (I say this because once we have the sources on a "cloud" term BTW rejected by myself and for once and all by RMS), will be given to anyone in a public "virtual network", so you can not ask them to release their packages in that other license if it is derivative or not see PM3. That's why I guess _DEC_ released it in the '94 as a pretty liberal to have just one. So we can have the idea of a "public cloud" and a private one in one and feel free to ask them to do so, anyway the DEC license doesn't prohibit linking against Modula-3 GPL libraries, or why is that lm is linked in Modula-3. You need to look at the facts and see that it can be licensed like that since it's your will to do so, but do your code need that is useless once again because it will bypassed anyway (is against that freedom you want). The world is not just one point, even in the "virtual networks", and everyone should be free to pass around software, that's the main "resource" of a society as RMS stays, is what creates a good society in which we can live in, even if you don't agree the arguments is clever enough to give it a try for such a society in digital terms this is free software and society around it that makes it if so. If none want that then it is pointless to ask the _DEC_ license to be free for RMS etc want that ever, as he did but was rejected by '88 to Olivetti, it is us who want that, theirs is their business to accept it or not (asking to give them the copyrights seems like they can change their license to whatever they like and I can't agree with that as well, as _DEC_ I think didn't agree to do in their time their efforts to do so). Indeed _DEC_ tried with '94 license, whatever it feels right now for FSF I don't know but I like more the idea of having 2 licenses, since it's us who want that change, but again, giving it two or three or more licenses makes no much sense for my point of view if anyone wants that, it is useless, that's the point of the unique '94 license, much more liberty that anyone can have (RMS before '94 denial is a show of that as well, I agree with you on that). Thanks in advance --- El s?b, 26/11/11, vintagecoder at aol.com escribi?: > De: vintagecoder at aol.com > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: s?bado, 26 de noviembre, 2011 13:35 > >> The Critical Mass license is > perfectly fine. What is the sick fascination > >> with GPL? > > >Just that a lot of free software *is* released inder > the GPL, and it > >would be convenient to be compatible. > > A lot of /Linux/ software has been infected by GPL's viral > forcible open > source license. BSD and MIT licenses existed before GPL, > they are truly > /free/ and open source licenses, and they are also > compatible with the GPL > (for me that compatibility is worth nothing). > > If you use the GPL you will contaminate the original DEC > license and > people who would have contributed or included your software > in situations > where BSD and MIT licenses are common and accepted but who > don't like GPL > (OpenBSD for a notable example) will have problems with it. > I personally > have a problem with it. I was very pleased to find CM3 and > the SRC license > and I would be very dissapointed if it was contaminated by > the GPL in the > future. > > If you are going for freedom, there are a few good choices > and none of them > are GPL. I cannot any reason other than politics for adding > the GPL to a > preexisting product. I sincerely hope elegosoft avoids > this! > > >> Why can't people just leave things alone and not > try to force > >> other people to live according to their rules. > LGPL is just a slippery > >> slope. > > > > Just trying to reduce future barriers to > interoperation. > > > >> Really? The GPL never reduced any barriers. It is > *all about* barriers. > > > It's about limiting one's freedom to limit others' > freedom. And that is > > a barrrier, right. But the way to bypass the > barrier is to release code > > under multiple licences, the GPL or LGPL together with > whatever licence > > you prefer. Potential users can then choose > whichever licence suits > > them. > > Mixing and matching licenses doesn't help because the GPL > adds restrictions > that aren't present in true free open source licenses. If > you feel it > necessary to license, what is the reason? Do you want to > maintain ownership > and foster community participation? Then use BSD or MIT > licenses which are > compatible with any open source license. Do you want to > make a political > statement and jump on a bandwagon over a cliff to the point > where many big > operations won't touch your product for fear of having to > expose their > code? Choose GPL. The GPL is incompatible with most open > source licenses > because it is not free, it adds restrictions that other > licenses don't have. > > I read recently MINIX had said they are attempting to build > commercial > support and demand for their OS and they found the BSD > license a > significant help in doing that. They said many potential > customers object > to the GPL. > > From a standpoint of true freedom /and/ possible commercial > success the BSD > and MIT style licenses seem so obviously superior to a > viral forcible open > source license, I just can't see why anybody would choose > the GPL except > for purely political reasons. It's self destructive. > > >> You truly want to reduce future barriers? Then > public-domain your code or > >> use a BSD or MIT license. > > >Those licences would do, yes. I suspect they're > compatible with both > >the SRC licence (which the CM licence is based on) and > GPL (but can > >anyone confirm that?). > > Yes, I can confirm they're compatible from GPL's > standpoint. I don't know > about the DEC/SRC license. > > >> Or just use the Critical Mass license and stop > >> trying to turn everything into Linux. > > > It's actually on Windows that it's a particular > problem. It's usual to > > distribute binaries there. Most potential > Windows users don't have their > > own software development tools and can only use > prelinked binaries. > > I understand Windows users are mostly stuck with prebuilt > applications. I > don't understand what licensing considerations have to do > with that. If you > use the SRC license does that have any effect on the > executables? If so, > how will adding code with other licenses whether BSD, MIT, > or even GPL make > anything simpler or change anything? If the CM3 runtime is > included in the > SRC license then that is the low bar, that is, you will > only be able to add > restrictions to it, not remove any. If the runtime is not > included then I > think it would be extremely unwise to encumber it any > further. I feel it > would be unwise to encumber it any further in any case. > > > > From mika at async.caltech.edu Thu Nov 3 02:39:30 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Nov 2011 18:39:30 -0700 Subject: [M3devel] Trying to set up on AMD64_LINUX Message-ID: <20111103013930.50EAE1A2080@async.async.caltech.edu> Ran into an error I don't recognize, any ideas, anyone? myriam5% cm3 -commands --- building in AMD64_LINUX --- cd AMD64_LINUX ignoring ../src/m3overrides rm .M3SHIP rm .M3OVERRIDES inhale libm3core.m3x new source -> compiling ThreadPThreadC.c gcc -gstabs+ -m64 -fPIC -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/POSIX -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/PTHREAD -I../src/C/Common -I../src/float/C99 -I../src/time/POSIX -c ../src/thread/PTHREAD/ThreadPThreadC.c new "ThreadPThreadC.o" -> archiving libm3core.a rm libm3core.a fgrep m3gcdefs /ufs/arpa/mika/cm3/pkg/m3core/AMD64_LINUX/.M3EXPORTS 2>/dev/null >/dev/null rm libm3core.a rm libm3core.a.sa rm libm3core.so rm libm3core.so.5 rm libm3core.exp ar crus libm3core.a hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMac hine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.m o Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo gcc -gstabs+ -m64 -fPIC -Wl,-z,now -Wl,-z,origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/ufs/arpa/mika/cm3/bin/../lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RT Tipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMachine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo Poly Basis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.mo Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo -lm -pthread /usr/bin/ld: ThreadPThreadC.o: relocation R_X86_64_PC32 against `ThreadPThread__SignalHandler' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core Fatal Error: package build failed rm m3make.args cd .. % uname -a Linux noname5 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux From jay.krell at cornell.edu Thu Nov 3 03:16:18 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 02:16:18 +0000 Subject: [M3devel] Trying to set up on AMD64_LINUX In-Reply-To: <20111103013930.50EAE1A2080@async.async.caltech.edu> References: <20111103013930.50EAE1A2080@async.async.caltech.edu> Message-ID: Possible a gcc bug. Possibly related to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 Possible fix is to stop using attribte(hidden) and such, but really, they are good things. I can poke around later maybe. I think AMD64_LINUX is a relatively popular platform here. Try with a newer gcc/ld? Try removing this: #if __GNUC__ >= 4 #pragma GCC visibility push(hidden) #endif in ThreadPThreadC.c. if that works, let's keep it, but move stuff around. Like, maybe move void SignalHandler(int signo, siginfo_t *info, void *context); above it, or put another decoration on that. - Jay > To: m3devel at elegosoft.com > Date: Wed, 2 Nov 2011 18:39:30 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] Trying to set up on AMD64_LINUX > > Ran into an error I don't recognize, any ideas, anyone? > > myriam5% cm3 -commands > --- building in AMD64_LINUX --- > > cd AMD64_LINUX > ignoring ../src/m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale libm3core.m3x > > new source -> compiling ThreadPThreadC.c > gcc -gstabs+ -m64 -fPIC -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/POSIX -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/PTHREAD -I../src/C/Common -I../src/float/C99 -I../src/time/POSIX -c ../src/thread/PTHREAD/ThreadPThreadC.c > > new "ThreadPThreadC.o" -> archiving libm3core.a > rm libm3core.a > fgrep m3gcdefs /ufs/arpa/mika/cm3/pkg/m3core/AMD64_LINUX/.M3EXPORTS 2>/dev/null >/dev/null > rm libm3core.a > rm libm3core.a.sa > rm libm3core.so > rm libm3core.so.5 > rm libm3core.exp > ar crus libm3core.a hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMac > hine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo > DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.m > o Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo > gcc -gstabs+ -m64 -fPIC -Wl,-z,now -Wl,-z,origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/ufs/arpa/mika/cm3/bin/../lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RT > Tipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMachine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io > M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo Poly > Basis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.mo Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo -lm -pthread > /usr/bin/ld: ThreadPThreadC.o: relocation R_X86_64_PC32 against `ThreadPThread__SignalHandler' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3core > Fatal Error: package build failed > rm m3make.args > cd .. > > % uname -a > Linux noname5 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 07:24:54 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 06:24:54 +0000 Subject: [M3devel] Target.i3/Target.m3 reduction? Message-ID: There is fairly little target-dependent-ness in our system, aside from the gcc code. I would like to reduce it. There are a few forms: There is dependency on word size. This I don't see removing any time soon, given that the front end does layout of records and computation of field offsets. There is dependency on jumpbuf size. We mostly know how to remove this, but have failed so far. The generated code should use alloca for the locals. (and even then, longer term, don't use setjmp/longjmp). We have these big arrays of targets, esp. in m3middle/src/Target.i3: PA32_HPUX, PA64_HPUX, PPC32_OPENBSD, PPC64_DARWIN, PPC_DARWIN, PPC_LINUX, ... Many of the dependencies are really per architecture or per kernel, not per architecture x kernel combination. So this almost-cross product seems dumb. Suggestions? There is dependency on endianness. This is what I'm really focusing on. I think this only matters for interop with C bitfields. We have no C bitfields in our system now. And the frontend and backend I think have to agree...oh, nevermind, I don't see that in parse.c > Aligned_procedures Just be safe and assume this is always false? Or it is a nice optimization on the common x86/AMD64 platforms? > First_readable_addr Just hardcode this as 4K? Instead of the slight optimization of setting it to 8K for SPARC? > Allow_packed_byte_aligned The safe value here is false. We set it to true only for x86/AMD64. I think true is probably safe for all architectures but older Alphas. ? > Setjmp This has the same value on platforms except VMS. We can maybe provide a portably-named wrapper? Maybe not, since this function is kind of special. I have to go.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Nov 3 07:50:21 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Nov 2011 23:50:21 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20111103055141.DE9FECC8A7@birch.elegosoft.com> References: <20111103055141.DE9FECC8A7@birch.elegosoft.com> Message-ID: <20111103065021.EC1341A2080@async.async.caltech.edu> Hi Jay, This does seem to have fixed the problem, as far as I can tell. Thanks as always. Mika Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 11/11/03 06:51:41 > >Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c > >Log message: > declare SignalHandler before pragma GCC visibility push(hidden), see if > it helps From jay.krell at cornell.edu Thu Nov 3 08:09:07 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 07:09:07 +0000 Subject: [M3devel] new CVS commit output? Message-ID: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v <-- Alpha64.common new revision: 1.4; previous revision: 1.3 cDebug turned on... $VAR1 = [ 'cm3/m3-sys/cminstall/src/config-no-install', 'ALPHA_LINUX', 'ALPHA_OPENBSD', 'Alpha64.common' ]; module - cm3 dir - path - files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX ALPHA_OPENBSD Alpha64.common id - 21684 Searching for log file index... found log file at 0.21684, now writing tmp files. Checking current dir against last dir. Current directory cm3/m3-sys/cminstall/src/config-no-install is last directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all commits done. format_lists(): cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. ARGV -> -d -m m3commit at elegosoft.com -s -M cm3 -f ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 08:28:01 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 07:28:01 +0000 Subject: [M3devel] CM3 on IA64? In-Reply-To: <1317708354.1319.2.camel@zx6000.hecnet.eu> References: <4E8A34A9.6070704@wickensonline.co.uk>, , <1317699760.16995.YahooMailClassic@web29708.mail.ird.yahoo.com>, , <1317708354.1319.2.camel@zx6000.hecnet.eu> Message-ID: 1) I didn't get the error you got, but I fixed it anyway. 2) Please try this: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-IA64_LINUX-d5.9.0-20111103.tgz Which is the output of ./boot1.py IA64_LINUX. 3) Can you help me update this code: #elif defined(__linux) #if defined(__i386) context->uc_mcontext.gregs[REG_EIP] #elif defined(__amd64) context->uc_mcontext.gregs[REG_RIP] #elif defined(__powerpc) context->uc_mcontext.uc_regs->gregs[PT_NIP] #elif defined(__arm__) context->uc_mcontext.arm_pc #elif defined(__alpha__) context->uc_mcontext.sc_pc #else #error unknown __linux target #endif You will hit this #error with that .tar.gz. or I guess please give me access to the machine, thank you. My ssh public key is attached. (I think it is time I generate new keys though..) Thank you, - Jay > Subject: RE: [M3devel] CM3 on IA64? > From: mark at wickensonline.co.uk > To: jay.krell at cornell.edu > CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com > Date: Tue, 4 Oct 2011 07:05:54 +0100 > > Jay, > > If you do ever feel like tackling the problem again I can give you > access to Alpha and IA64 OpenVMS boxes as required. > > Regards, Mark. > > On Tue, 2011-10-04 at 05:24 +0000, Jay K wrote: > > VMS is a more difficult port..except that it is approaching Posix > > these days. > > I had it far along, for Alpha. My system wasn't up to date wrt Posix > > features. > > Linux on IA64 should be very easy. > > > > - Jay > > > > > > > Date: Tue, 4 Oct 2011 04:42:40 +0100 > > > From: dabenavidesd at yahoo.es > > > To: m3devel at elegosoft.com; mark at wickensonline.co.uk > > > Subject: Re: [M3devel] CM3 on IA64? > > > > > > Hi all: > > > you might find surprisingly more clients for the same platform: > > > http://unix.derkeiler.com/Newsgroups/comp.os.vms/2004-03/0130.html > > > > > > In the news of Ken Olsen's obituary, they mentioned how DEC was not > > about micros, then it would explain some interest on the language in > > that, besides not too many Mainframes machine are build this days, I > > would certainly interested in to take a look about what it can do > > about in OpenVMS (a native port of threads for instance, could be > > interesting). I don't know any Mainframe OSes, would run this days, > > Linux. If OpenVMS has the sources for purchase, would they license > > freely to construct replicas, etc? The post sounds it may take it up > > to that point if people gets involved. Obviously IA64 is just another > > beast but who cares that matter right now. > > > OK, maybe there is that Modula-3 has its kind of EE, would you > > matter to ask what is that? > > > http://www.computer.org/portal/web/csdl/doi/10.1109/4236.991448 > > > > > > It could be that of DoD Generic Trusted Intermediaries GTI, which > > was constructed for among others Trusted Solaris and alike is related, > > But,the thing is who is using it right now or used it. > > > doi:10.1080/10658989709342533 > > > > > > Thanks in advance > > > > > > --- El lun, 3/10/11, Mark Wickens > > escribi?: > > > > > > > De: Mark Wickens > > > > Asunto: [M3devel] CM3 on IA64? > > > > Para: m3devel at elegosoft.com > > > > Fecha: lunes, 3 de octubre, 2011 17:18 > > > > Hi guys, > > > > > > > > Has anyone attempted a port of CM3 to Itanium > > > > architecture? > > > > I've recently installed gentoo on my ZX6000 and it's all > > > > running very nicely. > > > > My thoughts turned to what would be involved in getting > > > > Modula-3 running. > > > > > > > > Kind regards, Mark. > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: id_dsa.pub Type: application/octet-stream Size: 600 bytes Desc: not available URL: From michael.anderson at elegosoft.com Thu Nov 3 10:52:47 2011 From: michael.anderson at elegosoft.com (Michael Anderson) Date: Thu, 03 Nov 2011 10:52:47 +0100 Subject: [M3devel] new CVS commit output? In-Reply-To: References: Message-ID: <4EB2646F.6090704@elegosoft.com> Indeed. There is some extra debugging output to help me figure out a problem with path parsing in the cvs log/mailer scripts. I'll have that fixed up shortly. Sorry for the console spam. Mike Am 11/3/11 8:09 AM, schrieb Jay K: > > > > /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v > <-- Alpha64.common > new revision: 1.4; previous revision: 1.3 > cDebug turned on... > $VAR1 = [ > 'cm3/m3-sys/cminstall/src/config-no-install', > 'ALPHA_LINUX', > 'ALPHA_OPENBSD', > 'Alpha64.common' > ]; > > module - cm3 > dir - > path - > files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX > ALPHA_OPENBSD Alpha64.common > id - 21684 > Searching for log file index... found log file at 0.21684, now writing > tmp files. > Checking current dir against last dir. > Current directory cm3/m3-sys/cminstall/src/config-no-install is last > directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all > commits done. > format_lists(): > cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common > format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; > files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. > ARGV -> > -d > -m > m3commit at elegosoft.com > -s > -M > cm3 > -f > > > > ? > > - Jay -- Michael Anderson IT Services& Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 17:57:05 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 16:57:05 +0000 Subject: [M3devel] new CVS commit output? In-Reply-To: <4EB2646F.6090704@elegosoft.com> References: , <4EB2646F.6090704@elegosoft.com> Message-ID: No problem. I'm just making sure it is expected. - Jay Date: Thu, 3 Nov 2011 10:52:47 +0100 From: michael.anderson at elegosoft.com To: m3devel at elegosoft.com Subject: Re: [M3devel] new CVS commit output? Indeed. There is some extra debugging output to help me figure out a problem with path parsing in the cvs log/mailer scripts. I'll have that fixed up shortly. Sorry for the console spam. Mike Am 11/3/11 8:09 AM, schrieb Jay K: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v <-- Alpha64.common new revision: 1.4; previous revision: 1.3 cDebug turned on... $VAR1 = [ 'cm3/m3-sys/cminstall/src/config-no-install', 'ALPHA_LINUX', 'ALPHA_OPENBSD', 'Alpha64.common' ]; module - cm3 dir - path - files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX ALPHA_OPENBSD Alpha64.common id - 21684 Searching for log file index... found log file at 0.21684, now writing tmp files. Checking current dir against last dir. Current directory cm3/m3-sys/cminstall/src/config-no-install is last directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all commits done. format_lists(): cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. ARGV -> -d -m m3commit at elegosoft.com -s -M cm3 -f ? - Jay -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Nov 4 08:30:10 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 04 Nov 2011 00:30:10 -0700 Subject: [M3devel] adding new target? Message-ID: <20111104073010.D20E21A2080@async.async.caltech.edu> Hi Jay, I know you have mentioned before that it's now "easy" to add a new target. I would like to add a target that is already mostly there, I think. The one I want is mipsel-linux. This is to run on an Asus RT-N16 router running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors and 128 MB of DRAM. First before you read this email, are there any instructions for what I'm trying to do anywhere, beyond your emails? I am using boot1.py as you suggested. What I did was the following (guesses all along): made a cm3.cfg which I called MIPSEL_LINUX and put in m3-sys/cminstall/src/config-no-install: :::: readonly TARGET = "MIPSEL_LINUX" % code generation target readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler SYSTEM_ASM = "as" % Assembler m3back_m32 = "" % -m32 not allowed include("MIPSEL.common") include("Linux.common") :::: where MIPSEL.common contains: :::: readonly TARGET_ARCH = "MIPS" readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } :::: Now I don't really know which of these strings are just arbitrary strings that I'm defining here and which of them have to match other things (and if so, what they have to match). In any case I'm doing something wrong because I do (on a FreeBSD4 machine)... ./boot1.py MIPSEL_LINUX which runs for a bit and eventually degenerates to gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log gmake: `libcpp.a' is up to date. cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log gmake: `s-modes' is up to date. gmake: `insn-config.h' is up to date. gmake: Nothing to be done for `m3cg'. --- building in FreeBSD4 --- new source -> compiling RTHooks.i3 ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic new source -> compiling RT0.i3 ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RT0.ic new source -> compiling RuntimeError.i3 ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 ... Mika From dabenavidesd at yahoo.es Fri Nov 4 17:28:29 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 16:28:29 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: <20111104073010.D20E21A2080@async.async.caltech.edu> Message-ID: <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> Hi all: Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false This is a must in terms of addresanility, besides others like the endianess or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: http://www.fortunecity.com/skyscraper/motorola/22/resume.htm ). At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: http://www.youtube.com/watch?v=WUfvvFD5tAA. I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): http://users.crocker.com/~hudson/hudson.html Thanks in advance --- El vie, 4/11/11, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: [M3devel] adding new target? > Para: m3devel at elegosoft.com > Fecha: viernes, 4 de noviembre, 2011 02:30 > Hi Jay, > > I know you have mentioned before that it's now "easy" to > add a new target. > I would like to add a target that is already mostly there, > I think. > The one I want is mipsel-linux. This is to run on an > Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz > MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any > instructions for what > I'm trying to do anywhere, beyond your emails? I am > using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { > "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { > "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just > arbitrary > strings that I'm defining here and which of them have to > match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a > FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** > illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal > error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > > From jay.krell at cornell.edu Fri Nov 4 17:35:06 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 16:35:06 +0000 Subject: [M3devel] adding new target? In-Reply-To: <20111104073010.D20E21A2080@async.async.caltech.edu> References: <20111104073010.D20E21A2080@async.async.caltech.edu> Message-ID: Please put "32" in the name of the target? That's just preference/taste, not a requirement. > cd ../FreeBSD4-I386_FREEBSD We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. I realize that is also confusing. But it is how you can transition from the old target names to the new ones. > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 And then later on we probably confused .ic/.mc files for assembly source or vice versa. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. grep -r -i linux m3makefile *quake* or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? - Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 18:07:52 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 17:07:52 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: Message-ID: <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: in that case, it isn't the LINUXLIBC6 a better name for these targets (at least in Debian 3.0 or so), I mean, not necessarily embedded speaking. And then what does it mean that is not more or less upward "compatibility". Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] adding new target? Para: "Mika Nystrom" , "m3devel" Fecha: viernes, 4 de noviembre, 2011 11:35 ?Please put "32" in the name of the target? That's just preference/taste, not a requirement. ? > cd ../FreeBSD4-I386_FREEBSD ?We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. ?I realize that is also confusing. But it is how you can transition from the old target names to the new ones. ? > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5? ? And then later on we probably confused .ic/.mc files for assembly source or vice versa.? ?See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. ?We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. ?grep -r -i linux m3makefile *quake*? or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? ?- Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 4 18:36:58 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 17:36:58 +0000 Subject: [M3devel] adding new target? In-Reply-To: <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> References: , <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: Eh, maybe. Maybe MIPS32EL_LINUXLIBC6. I'm really not familiar with the versions. I think prior to 6 wasn't glibc and >=6 is glibc, and it probably hasn't gone to 7. In which case, no. This is also a confusing name, because almost nobody knows what "libc6" implies. Consider that most users weren't around before. And even I'm not sure what it means. I do believe the kernel version is relevant here also. That 2.4 never had decent pthreads, never had NPTL. But Linux certainly has had pthreads since long before 2.6/NPTL. - Jay Date: Fri, 4 Nov 2011 17:07:52 +0000 From: dabenavidesd at yahoo.es To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] adding new target? Hi all: in that case, it isn't the LINUXLIBC6 a better name for these targets (at least in Debian 3.0 or so), I mean, not necessarily embedded speaking. And then what does it mean that is not more or less upward "compatibility". Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] adding new target? Para: "Mika Nystrom" , "m3devel" Fecha: viernes, 4 de noviembre, 2011 11:35 Please put "32" in the name of the target? That's just preference/taste, not a requirement. > cd ../FreeBSD4-I386_FREEBSD We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. I realize that is also confusing. But it is how you can transition from the old target names to the new ones. > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 And then later on we probably confused .ic/.mc files for assembly source or vice versa. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. grep -r -i linux m3makefile *quake* or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? - Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 4 18:39:19 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 17:39:19 +0000 Subject: [M3devel] adding new target? In-Reply-To: <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> References: <20111104073010.D20E21A2080@async.async.caltech.edu>, <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> Message-ID: > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. - Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 19:08:29 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 18:08:29 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: Message-ID: <1320430109.66209.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: well, but nonetheless, like first DEC pdp-10 didn't have those: http://www.xkl.com/darkstar.html Even today I doubt modern pdp-10 would have it or not, maybe I guess. In retrospective you sort of fell like you could build your own OS for those big machines, even now, why wouldn't one think the same way. I think they even created paging hardware and basically the same sort of handling would depend on the OS itself as well to handle it (they had ported some Unix from AT&T and BSD of historic value but I don't know even a Linux distro that runs on it or something like that, well maybe some emulator). http://en.wikipedia.org/wiki/SIMH#Digital_Equipment_Corporation The interest on this stuff is the packet fields and BITS types of Modula-3, wouldn't be nice to have those on a recent hardware implementations? But then we would need to address the INTEGER issues, and etc (p.d they have ported gcc to there, so this is fact possible: http://gcc.gnu.org/ml/gcc/2008-04/msg00516.html ) Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] adding new target? Para: dabenavidesd at yahoo.es, "m3devel" , "Mika Nystrom" Fecha: viernes, 4 de noviembre, 2011 12:39 > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. ?- Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 23:31:52 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 22:31:52 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: <1320430109.66209.YahooMailClassic@web29707.mail.ird.yahoo.com> Message-ID: <1320445912.67026.YahooMailClassic@web29713.mail.ird.yahoo.com> Hi all: in fact there are even new hardware hacks for that as well, someones in practice: http://homepage.mac.com/dgcx/pdp10x/ http://www.freak-search.com/en/thread/3102486/its_starting_to_be_a_pdp-10 Besides that I think the Thread implementation on SRC Modula-3 used to depend on an instruction that the Pdp-10 could execute so we can afford to compete one of those beasts with modern ones to see real and emulated performance, if one such DECiestis interested: http://www.webservertalk.com/archive154-2006-5-1505344.html I would host on of those, but how much power does it consume, very angry machine, although important steps for history of Computation, maybe in a virtual museum :) https://www.msu.edu/~mrr/mycomp/cdc6000/cdc_emulators.htm Thanks in advance --- El vie, 4/11/11, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] adding new target? Para: "m3devel" , "Mika Nystrom" , "Jay K" Fecha: viernes, 4 de noviembre, 2011 13:08 Hi all: well, but nonetheless, like first DEC pdp-10 didn't have those: http://www.xkl.com/darkstar.html Even today I doubt modern pdp-10 would have it or not, maybe I guess. In retrospective you sort of fell like you could build your own OS for those big machines, even now, why wouldn't one think the same way. I think they even created paging hardware and basically the same sort of handling would depend on the OS itself as well to handle it (they had ported some Unix from AT&T and BSD of historic value but I don't know even a Linux distro that runs on it or something like that, well maybe some emulator). http://en.wikipedia.org/wiki/SIMH#Digital_Equipment_Corporation The interest on this stuff is the packet fields and BITS types of Modula-3, wouldn't be nice to have those on a recent hardware implementations? But then we would need to address the INTEGER issues, and etc (p.d they have ported gcc to there, so this is fact possible: http://gcc.gnu.org/ml/gcc/2008-04/msg00516.html ) Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] adding new target? Para: dabenavidesd at yahoo.es, "m3devel" , "Mika Nystrom" Fecha: viernes, 4 de noviembre, 2011 12:39 > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. ?- Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Tue Nov 15 23:44:17 2011 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 15 Nov 2011 22:44:17 +0000 Subject: [M3devel] m2tom3 Message-ID: <4EC2EB41.6010203@wickensonline.co.uk> Guys, I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz I attempted to compile it using cm3, but I get an unknown interface: msw at x60:~/m2tom3/m2tom3/src$ cm3 --- building in ../LINUXLIBC6 --- unsupported m3_option value: "-O" new source -> compiling Standard.m3 "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) 1 error encountered compilation failed => not building program "m2tom3" Fatal Error: package build failed Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. Regards, Makr. From rcolebur at SCIRES.COM Wed Nov 16 00:17:33 2011 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 15 Nov 2011 18:17:33 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: Mark: I seem to recall that "TextF" was for "Text Friends" and that it was removed after Critical Mass changed the underlying TEXT representation to deal with the new wide character sets. Here is a link that describes it a bit more: http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes So, you will need to recode any operations that used the old TextF interface. If you want, I'll look around and see if I have an old copy of TextF laying around that you can review to see what code you will need to implement. I don't think it will be too much work. Let me know if you need it. Perhaps someone else on this thread has already done something along these lines. Regards, Randy Coleburn -----Original Message----- From: Mark Wickens [mailto:mark at wickensonline.co.uk] Sent: Tuesday, November 15, 2011 5:44 PM To: m3devel Subject: [M3devel] m2tom3 Guys, I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz I attempted to compile it using cm3, but I get an unknown interface: msw at x60:~/m2tom3/m2tom3/src$ cm3 --- building in ../LINUXLIBC6 --- unsupported m3_option value: "-O" new source -> compiling Standard.m3 "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) 1 error encountered compilation failed => not building program "m2tom3" Fatal Error: package build failed Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. Regards, Makr. From mika at async.caltech.edu Wed Nov 16 00:24:57 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 15 Nov 2011 15:24:57 -0800 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <20111115232457.78E2C1A205B@async.async.caltech.edu> What I would do is: 1. delete IMPORT TextF 2. see what breaks, figure out the intent of the code, recode it using Text 3. check in the result to the CM3 repository so no one has to do it again! Mika Mark Wickens writes: >Guys, > >I found the m2tom3 translation utility here: >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >I attempted to compile it using cm3, but I get an unknown interface: > >msw at x60:~/m2tom3/m2tom3/src$ cm3 >--- building in ../LINUXLIBC6 --- > >unsupported m3_option value: "-O" >new source -> compiling Standard.m3 >"../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >1 error encountered >compilation failed => not building program "m2tom3" >Fatal Error: package build failed > > >Has anyone heard of interface TextF? Alternatively, is there a port of >this utility to cm3? > >I recently uncovered a machine-readable copy of my degree final year >project, a Meta Assembler, written in Modula-2, and wondered if I could >get it to compile using the utility to work with Modula-3. > >Regards, > >Makr. From dabenavidesd at yahoo.es Wed Nov 16 01:22:31 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 00:22:31 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111115232457.78E2C1A205B@async.async.caltech.edu> Message-ID: <1321402951.28257.YahooMailClassic@web29714.mail.ird.yahoo.com> Hi all: yeah my fault, but as I recall although I could compile this years ago, the main issue is that it didn't even work to feed the file to compile or so failed in therefore the first character was read. So it never worked for real for me. My best bet would export a SUN Unix syscall interface (since it tailored the SUN Modula-2 library) spec like Sphinx in SPIN OS so an export of it for every Modula-3 program understands itself right (yeah it coudl take the years spent from when I compiled until today, or so). If I were to start a new project perhaps would start making Unix legacy and updated replacements. The other approach perhaps the most indicated is just to wrap C on SPIN code to make it user level server. This could make the thing (inf act there is FreeBSD server already there just miss several calls, but nonetheless is something there). BTW, I don' know which platform this compiler used to work, so the main point would be emulate the real sys calls, since they just emulated in Sun OS and Solaris, nothing more. This has a potential utility for another project that depends on this m2tom3 tool. Thanks in advance --- El mar, 15/11/11, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 18:24 > What I would do is: > > 1. delete IMPORT TextF > 2. see what breaks, figure out the intent of the code, > recode it using Text > 3. check in the result to the CM3 repository so no one has > to do it again! > > Mika > > Mark Wickens writes: > >Guys, > > > >I found the m2tom3 translation utility here: > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > >I attempted to compile it using cm3, but I get an > unknown interface: > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > >--- building in ../LINUXLIBC6 --- > > > >unsupported m3_option value: "-O" > >new source -> compiling Standard.m3 > >"../src/Analyzer/Standard.m3", line 25: unable to find > interface (TextF) > >1 error encountered > >compilation failed => not building program "m2tom3" > >Fatal Error: package build failed > > > > > >Has anyone heard of interface TextF? Alternatively, is > there a port of > >this utility to cm3? > > > >I recently uncovered a machine-readable copy of my > degree final year > >project, a Meta Assembler, written in Modula-2, and > wondered if I could > >get it to compile using the utility to work with > Modula-3. > > > >Regards, > > > >Makr. > From dabenavidesd at yahoo.es Wed Nov 16 02:22:35 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 01:22:35 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321402951.28257.YahooMailClassic@web29714.mail.ird.yahoo.com> Message-ID: <1321406555.89220.YahooMailClassic@web29720.mail.ird.yahoo.com> Hi all: just forget that, it's done, the only thing we need is the SUN Modula-2 compilers, and that's all folks :) http://homepage.mac.com/dr2chase/resume.html How enough hard this men worked but how much good fellows they were (I can't see anything like this today in industry). Thanks in advance --- El mar, 15/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 19:22 > Hi all: > yeah my fault, but as I recall although I could compile > this years ago, the main issue is that it didn't even work > to feed the file to compile or so failed in therefore the > first character was read. So it never worked for real for > me. > My best bet would export a SUN Unix syscall interface > (since it tailored the SUN Modula-2 library) spec like > Sphinx in SPIN OS so an export of it for every Modula-3 > program understands itself right (yeah it coudl take the > years spent from when I compiled until today, or so). > If I were to start a new project perhaps would start making > Unix legacy and updated replacements. > The other approach perhaps the most indicated is just to > wrap C on SPIN code to make it user level server. This could > make the thing (inf act there is FreeBSD server already > there just miss several calls, but nonetheless is something > there). > BTW, I don' know which platform this compiler used to work, > so the main point would be emulate the real sys calls, since > they just emulated in Sun OS and Solaris, nothing more. This > has a potential utility for another project that depends on > this m2tom3 tool. > Thanks in advance > > --- El mar, 15/11/11, Mika Nystrom > escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 18:24 > > What I would do is: > > > > 1. delete IMPORT TextF > > 2. see what breaks, figure out the intent of the > code, > > recode it using Text > > 3. check in the result to the CM3 repository so no one > has > > to do it again! > > > > Mika > > > > Mark Wickens writes: > > >Guys, > > > > > >I found the m2tom3 translation utility here: > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > >I attempted to compile it using cm3, but I get an > > unknown interface: > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > >--- building in ../LINUXLIBC6 --- > > > > > >unsupported m3_option value: "-O" > > >new source -> compiling Standard.m3 > > >"../src/Analyzer/Standard.m3", line 25: unable to > find > > interface (TextF) > > >1 error encountered > > >compilation failed => not building program > "m2tom3" > > >Fatal Error: package build failed > > > > > > > > >Has anyone heard of interface TextF? > Alternatively, is > > there a port of > > >this utility to cm3? > > > > > >I recently uncovered a machine-readable copy of > my > > degree final year > > >project, a Meta Assembler, written in Modula-2, > and > > wondered if I could > > >get it to compile using the utility to work with > > Modula-3. > > > > > >Regards, > > > > > >Makr. > > > From dabenavidesd at yahoo.es Wed Nov 16 20:56:59 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 19:56:59 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321406555.89220.YahooMailClassic@web29720.mail.ird.yahoo.com> Message-ID: <1321473419.50950.YahooMailClassic@web29720.mail.ird.yahoo.com> Hi all: I think this is the way to get out of this "moral-technical" issue with the Unix interfaces, so get back to the old style (of course not brutal cross product), though we could that for the sake of further compatibility (it should be transparent ideally, like an Universal VM), but compiled natively (DEC SRC had the Ultrix VAX API as well, so for vax, openVMS you could do that surely). And at the end just EXPORT Unix.System() or UnixV, UnixVI, etc and that's all. OK, let me know, thanks in advance --- El mar, 15/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 20:22 > Hi all: > just forget that, it's done, the only thing we need is the > SUN Modula-2 compilers, and that's all folks :) > http://homepage.mac.com/dr2chase/resume.html > > How enough hard this men worked but how much good fellows > they were (I can't see anything like this today in > industry). > > Thanks in advance > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > escribi?: > > > De: Daniel Alejandro Benavides D. > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" , > "Mika Nystrom" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 19:22 > > Hi all: > > yeah my fault, but as I recall although I could > compile > > this years ago, the main issue is that it didn't even > work > > to feed the file to compile or so failed in therefore > the > > first character was read. So it never worked for real > for > > me. > > My best bet would export a SUN Unix syscall interface > > (since it tailored the SUN Modula-2 library) spec > like > > Sphinx in SPIN OS so an export of it for every > Modula-3 > > program understands itself right (yeah it coudl take > the > > years spent from when I compiled until today, or so). > > If I were to start a new project perhaps would start > making > > Unix legacy and updated replacements. > > The other approach perhaps the most indicated is just > to > > wrap C on SPIN code to make it user level server. This > could > > make the thing (inf act there is FreeBSD server > already > > there just miss several calls, but nonetheless is > something > > there). > > BTW, I don' know which platform this compiler used to > work, > > so the main point would be emulate the real sys calls, > since > > they just emulated in Sun OS and Solaris, nothing > more. This > > has a potential utility for another project that > depends on > > this m2tom3 tool. > > Thanks in advance > > > > --- El mar, 15/11/11, Mika Nystrom > > escribi?: > > > > > De: Mika Nystrom > > > Asunto: Re: [M3devel] m2tom3 > > > Para: "Mark Wickens" > > > CC: m3devel at elegosoft.com > > > Fecha: martes, 15 de noviembre, 2011 18:24 > > > What I would do is: > > > > > > 1. delete IMPORT TextF > > > 2. see what breaks, figure out the intent of the > > code, > > > recode it using Text > > > 3. check in the result to the CM3 repository so > no one > > has > > > to do it again! > > > > > > Mika > > > > > > Mark Wickens writes: > > > >Guys, > > > > > > > >I found the m2tom3 translation utility here: > > > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > >I attempted to compile it using cm3, but I > get an > > > unknown interface: > > > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > >--- building in ../LINUXLIBC6 --- > > > > > > > >unsupported m3_option value: "-O" > > > >new source -> compiling Standard.m3 > > > >"../src/Analyzer/Standard.m3", line 25: > unable to > > find > > > interface (TextF) > > > >1 error encountered > > > >compilation failed => not building > program > > "m2tom3" > > > >Fatal Error: package build failed > > > > > > > > > > > >Has anyone heard of interface TextF? > > Alternatively, is > > > there a port of > > > >this utility to cm3? > > > > > > > >I recently uncovered a machine-readable copy > of > > my > > > degree final year > > > >project, a Meta Assembler, written in > Modula-2, > > and > > > wondered if I could > > > >get it to compile using the utility to work > with > > > Modula-3. > > > > > > > >Regards, > > > > > > > >Makr. > > > > > > From dabenavidesd at yahoo.es Thu Nov 17 04:36:56 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 17 Nov 2011 03:36:56 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321473419.50950.YahooMailClassic@web29720.mail.ird.yahoo.com> Message-ID: <1321501016.42602.YahooMailClassic@web29709.mail.ird.yahoo.com> Hi all: and I see this: http://labs.oracle.com/forest/COM.Sun.Labs.Forest.doc.see_97.paper_pdf.pdf indicated that it was possible to either compile and cross-assemble or compile and run over its DEC-SRC Microkernel VMS code, at least at user-level. Anyway, the main thing here is that this cross-ports like SOLGnu or Darwin are actually possible to run in one compilation and two code generations. That is better functionality or at least I guess so for those platforms as well. Of course the idea would be run in SPIN, but in some cases like SPINE it can run actually NT386GNU and NT386 or for instance run in a LAN a NT_ALPHA_GNU (SPINE) and ALPHA_SPIN code almost instantly (like if it would an user-level server) alternatively or somehow a crazy thing like that in IX86 likewise setting. Thanks in advance --- El mi?, 16/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: mi?rcoles, 16 de noviembre, 2011 14:56 > Hi all: > I think this is the way to get out of this > "moral-technical" issue with the Unix interfaces, so get > back to the old style (of course not brutal cross product), > though we could that for the sake of further compatibility > (it should be transparent ideally, like an Universal VM), > but compiled natively (DEC SRC had the Ultrix VAX API as > well, so for vax, openVMS you could do that surely). > And at the end just EXPORT Unix.System() or UnixV, UnixVI, > etc and that's all. > OK, let me know, thanks in advance > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > escribi?: > > > De: Daniel Alejandro Benavides D. > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" , > "Mika Nystrom" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 20:22 > > Hi all: > > just forget that, it's done, the only thing we need is > the > > SUN Modula-2 compilers, and that's all folks :) > > http://homepage.mac.com/dr2chase/resume.html > > > > How enough hard this men worked but how much good > fellows > > they were (I can't see anything like this today in > > industry). > > > > Thanks in advance > > > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > > > escribi?: > > > > > De: Daniel Alejandro Benavides D. > > > Asunto: Re: [M3devel] m2tom3 > > > Para: "Mark Wickens" , > > "Mika Nystrom" > > > CC: m3devel at elegosoft.com > > > Fecha: martes, 15 de noviembre, 2011 19:22 > > > Hi all: > > > yeah my fault, but as I recall although I could > > compile > > > this years ago, the main issue is that it didn't > even > > work > > > to feed the file to compile or so failed in > therefore > > the > > > first character was read. So it never worked for > real > > for > > > me. > > > My best bet would export a SUN Unix syscall > interface > > > (since it tailored the SUN Modula-2 library) > spec > > like > > > Sphinx in SPIN OS so an export of it for every > > Modula-3 > > > program understands itself right (yeah it coudl > take > > the > > > years spent from when I compiled until today, or > so). > > > If I were to start a new project perhaps would > start > > making > > > Unix legacy and updated replacements. > > > The other approach perhaps the most indicated is > just > > to > > > wrap C on SPIN code to make it user level server. > This > > could > > > make the thing (inf act there is FreeBSD server > > already > > > there just miss several calls, but nonetheless > is > > something > > > there). > > > BTW, I don' know which platform this compiler > used to > > work, > > > so the main point would be emulate the real sys > calls, > > since > > > they just emulated in Sun OS and Solaris, > nothing > > more. This > > > has a potential utility for another project that > > depends on > > > this m2tom3 tool. > > > Thanks in advance > > > > > > --- El mar, 15/11/11, Mika Nystrom > > > escribi?: > > > > > > > De: Mika Nystrom > > > > Asunto: Re: [M3devel] m2tom3 > > > > Para: "Mark Wickens" > > > > CC: m3devel at elegosoft.com > > > > Fecha: martes, 15 de noviembre, 2011 18:24 > > > > What I would do is: > > > > > > > > 1. delete IMPORT TextF > > > > 2. see what breaks, figure out the intent of > the > > > code, > > > > recode it using Text > > > > 3. check in the result to the CM3 repository > so > > no one > > > has > > > > to do it again! > > > > > > > > Mika > > > > > > > > Mark Wickens writes: > > > > >Guys, > > > > > > > > > >I found the m2tom3 translation utility > here: > > > > > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > > >I attempted to compile it using cm3, but > I > > get an > > > > unknown interface: > > > > > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > > >--- building in ../LINUXLIBC6 --- > > > > > > > > > >unsupported m3_option value: "-O" > > > > >new source -> compiling Standard.m3 > > > > >"../src/Analyzer/Standard.m3", line 25: > > unable to > > > find > > > > interface (TextF) > > > > >1 error encountered > > > > >compilation failed => not building > > program > > > "m2tom3" > > > > >Fatal Error: package build failed > > > > > > > > > > > > > > >Has anyone heard of interface TextF? > > > Alternatively, is > > > > there a port of > > > > >this utility to cm3? > > > > > > > > > >I recently uncovered a machine-readable > copy > > of > > > my > > > > degree final year > > > > >project, a Meta Assembler, written in > > Modula-2, > > > and > > > > wondered if I could > > > > >get it to compile using the utility to > work > > with > > > > Modula-3. > > > > > > > > > >Regards, > > > > > > > > > >Makr. > > > > > > > > > > From rodney_bates at lcwb.coop Thu Nov 17 17:29:04 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Nov 2011 10:29:04 -0600 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <4EC53650.6070206@lcwb.coop> I have used m2tom3 successfully a couple of times in the (distant) past. There are a few places where the languages are different enough that you get either unidiomatic or unworkable translations. As I recall, the method of returning a function result will require some hand cleanup, and variant records, if you have them, will just be flattened, rather than converted to an object type hierarchy. Nevertheless, it will save a *lot* of tedious editing of mundane syntactic nits. TextF exposes PM3's internal representation of TEXT values, which is altogether different from that of CM3, so you will not be able to use it unless you use PM3. I am sure it is in the PM3 distribution at Elego, and I know I have copies around. By now, PM3 has probably suffered some bitrot, so installing it might take some work. I have an installation around on a machine that has not been powered up for a few months, but probably works. I probably also have a compiled executable for m2tom3 on LINUXLIBC6 that might run on a machine of that type. I could provide a copy of that, if you want to see if you can do it without putting in a lot of work. Or maybe I could just run it for you a few times. On 11/15/2011 04:44 PM, Mark Wickens wrote: > Guys, > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > I attempted to compile it using cm3, but I get an unknown interface: > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > --- building in ../LINUXLIBC6 --- > > unsupported m3_option value: "-O" > new source -> compiling Standard.m3 > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > 1 error encountered > compilation failed => not building program "m2tom3" > Fatal Error: package build failed > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > Regards, > > Makr. > > From rodney_bates at lcwb.coop Thu Nov 17 18:09:49 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Nov 2011 11:09:49 -0600 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <4EC53FDD.2040301@lcwb.coop> I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. The result is attached. It compiled and linked on AMD64_LINUX, and executed enough to give the help text and to translate a tiny bit of Modula-2 code. I'm biting my tongue on why it was coded this way in the first place. On 11/15/2011 04:44 PM, Mark Wickens wrote: > Guys, > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > I attempted to compile it using cm3, but I get an unknown interface: > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > --- building in ../LINUXLIBC6 --- > > unsupported m3_option value: "-O" > new source -> compiling Standard.m3 > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > 1 error encountered > compilation failed => not building program "m2tom3" > Fatal Error: package build failed > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > Regards, > > Makr. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Standard.m3 URL: From jay.krell at cornell.edu Thu Nov 17 18:57:53 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Nov 2011 17:57:53 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <4EC53FDD.2040301@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk>,<4EC53FDD.2040301@lcwb.coop> Message-ID: Commit the initial version, and then the revisions, to the cm3 repository? - Jay > Date: Thu, 17 Nov 2011 11:09:49 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m2tom3 > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > The result is attached. > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > and to translate a tiny bit of Modula-2 code. > > I'm biting my tongue on why it was coded this way in the first place. > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > Guys, > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > I attempted to compile it using cm3, but I get an unknown interface: > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > --- building in ../LINUXLIBC6 --- > > > > unsupported m3_option value: "-O" > > new source -> compiling Standard.m3 > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > 1 error encountered > > compilation failed => not building program "m2tom3" > > Fatal Error: package build failed > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > Regards, > > > > Makr. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Thu Nov 17 19:40:37 2011 From: mark at wickensonline.co.uk (Mark Wickens) Date: Thu, 17 Nov 2011 18:40:37 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <4EC53FDD.2040301@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC55525.8010904@wickensonline.co.uk> On 17/11/11 17:09, Rodney M. Bates wrote: > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > by eliminating IMPORT TextF and changing 4 places from the form > TextVariable[j] > to Text.GetChar(TextVariable,j). This is file > m2tom3/src/Analyzer/Standard,m3. > The result is attached. > > It compiled and linked on AMD64_LINUX, and executed enough to give the > help text > and to translate a tiny bit of Modula-2 code. > > I'm biting my tongue on why it was coded this way in the first place. > > On 11/15/2011 04:44 PM, Mark Wickens wrote: >> Guys, >> >> I found the m2tom3 translation utility here: >> http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >> I attempted to compile it using cm3, but I get an unknown interface: >> >> msw at x60:~/m2tom3/m2tom3/src$ cm3 >> --- building in ../LINUXLIBC6 --- >> >> unsupported m3_option value: "-O" >> new source -> compiling Standard.m3 >> "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >> 1 error encountered >> compilation failed => not building program "m2tom3" >> Fatal Error: package build failed >> >> >> Has anyone heard of interface TextF? Alternatively, is there a port >> of this utility to cm3? >> >> I recently uncovered a machine-readable copy of my degree final year >> project, a Meta Assembler, written in Modula-2, and wondered if I >> could get it to compile using the utility to work with Modula-3. >> >> Regards, >> >> Makr. >> >> Thanks Rodney, My M3 skills aren't up to much - I'll give it a whirl later. Regards, Mark. From michael.anderson at elegosoft.com Fri Nov 18 10:31:31 2011 From: michael.anderson at elegosoft.com (Michael Anderson) Date: Fri, 18 Nov 2011 10:31:31 +0100 Subject: [M3devel] [elego Server Maintenance] Friday, 18.11.2011 20:30 CET Message-ID: <4EC625F3.6030100@elegosoft.com> Hello, On Friday, November 18 at 8:30 PM CET, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services& Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Fri Nov 18 18:11:04 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:11:04 -0600 Subject: [M3devel] m2tom3 Standard.m3, second try. In-Reply-To: <4EC56C22.4040005@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> <4EC56C22.4040005@wickensonline.co.uk> Message-ID: <4EC691A8.7080200@lcwb.coop> Opps, sorry. That was the unmodified version. I seem to have two different subdirectories with m3tom3 in them. Try this one. On 11/17/2011 02:18 PM, Mark Wickens wrote: > On 17/11/11 17:09, Rodney M. Bates wrote: >> I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 >> by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] >> to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. >> The result is attached. >> >> It compiled and linked on AMD64_LINUX, and executed enough to give the help text >> and to translate a tiny bit of Modula-2 code. >> >> I'm biting my tongue on why it was coded this way in the first place. >> >> On 11/15/2011 04:44 PM, Mark Wickens wrote: >>> Guys, >>> >>> I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >>> I attempted to compile it using cm3, but I get an unknown interface: >>> >>> msw at x60:~/m2tom3/m2tom3/src$ cm3 >>> --- building in ../LINUXLIBC6 --- >>> >>> unsupported m3_option value: "-O" >>> new source -> compiling Standard.m3 >>> "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >>> 1 error encountered >>> compilation failed => not building program "m2tom3" >>> Fatal Error: package build failed >>> >>> >>> Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? >>> >>> I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. >>> >>> Regards, >>> >>> Makr. >>> >>> > Hi Rodney, is the version of Standard.m3 attached to your email the one you modified? > I can still see an import of TextF. > > Thanks for the help, > > Mark. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Standard.m3 URL: From rodney_bates at lcwb.coop Fri Nov 18 18:24:28 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:24:28 -0600 Subject: [M3devel] m2tom3 In-Reply-To: References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC694CC.1070004@lcwb.coop> Olaf, is there a place in the elego-hosted repositories I can put this? I don't find it already present in my local copy of cm3. Can I create a new subdirectory, say in cm3/m3-tools? On this topic, I have a few library packages that might be useful to somebody someday. Would Elegosoft be interested in hosting them? On 11/17/2011 11:57 AM, Jay K wrote: > Commit the initial version, and then the revisions, to the cm3 repository? > > - Jay > > Date: Thu, 17 Nov 2011 11:09:49 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m2tom3 > > > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > > The result is attached. > > > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > > and to translate a tiny bit of Modula-2 code. > > > > I'm biting my tongue on why it was coded this way in the first place. > > > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > > Guys, > > > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > I attempted to compile it using cm3, but I get an unknown interface: > > > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > --- building in ../LINUXLIBC6 --- > > > > > > unsupported m3_option value: "-O" > > > new source -> compiling Standard.m3 > > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > > 1 error encountered > > > compilation failed => not building program "m2tom3" > > > Fatal Error: package build failed > > > > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > > > Regards, > > > > > > Makr. > > > > > > From rodney_bates at lcwb.coop Fri Nov 18 18:25:22 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:25:22 -0600 Subject: [M3devel] m2tom3 In-Reply-To: References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC69502.4050800@lcwb.coop> Olaf, is there a place in the elego-hosted repositories I can put this? I don't find it already present in my local copy of cm3. Can I create a new subdirectory, say in cm3/m3-tools or cm3/tools? On this topic, I have a few library packages that might be useful to somebody someday. Would Elegosoft be interested in hosting them? On 11/17/2011 11:57 AM, Jay K wrote: > Commit the initial version, and then the revisions, to the cm3 repository? > > - Jay > > Date: Thu, 17 Nov 2011 11:09:49 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m2tom3 > > > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > > The result is attached. > > > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > > and to translate a tiny bit of Modula-2 code. > > > > I'm biting my tongue on why it was coded this way in the first place. > > > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > > Guys, > > > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > I attempted to compile it using cm3, but I get an unknown interface: > > > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > --- building in ../LINUXLIBC6 --- > > > > > > unsupported m3_option value: "-O" > > > new source -> compiling Standard.m3 > > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > > 1 error encountered > > > compilation failed => not building program "m2tom3" > > > Fatal Error: package build failed > > > > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > > > Regards, > > > > > > Makr. > > > > > > From wagner at elegosoft.com Wed Nov 23 10:53:18 2011 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Nov 2011 10:53:18 +0100 Subject: [M3devel] m2tom3 In-Reply-To: <4EC694CC.1070004@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> <4EC694CC.1070004@lcwb.coop> Message-ID: <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> Hi Rodney, sorry for answering so late. Quoting "Rodney M. Bates" : > Olaf, is there a place in the elego-hosted repositories I can put this? > I don't find it already present in my local copy of cm3. > Can I create a new subdirectory, say in cm3/m3-tools? Of course, just cvs-add it. Please make sure that it compiles though. > On this topic, I have a few library packages that might be useful > to somebody someday. Would Elegosoft be interested in hosting them? As long as you don't upload gigabytes of M3 source code (let us know of that in advance :-), please feel free to add and share any library that you think may be useful for others. We should probably add some documentation for them and re-run and ship the m3tohtml results to the web server, but that can be done later. Thanks for your contributions, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Nov 23 16:18:34 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 23 Nov 2011 10:18:34 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> <4EC694CC.1070004@lcwb.coop> <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> Message-ID: <20111123151833.GA13397@topoi.pooq.com> On Wed, Nov 23, 2011 at 10:53:18AM +0100, Olaf Wagner wrote: > Hi Rodney, > > sorry for answering so late. > > Quoting "Rodney M. Bates" : > > >Olaf, is there a place in the elego-hosted repositories I can put this? > >I don't find it already present in my local copy of cm3. > >Can I create a new subdirectory, say in cm3/m3-tools? > > Of course, just cvs-add it. Please make sure that it compiles though. > > >On this topic, I have a few library packages that might be useful > >to somebody someday. Would Elegosoft be interested in hosting them? > > As long as you don't upload gigabytes of M3 source code (let us know > of that in advance :-), please feel free to add and share any library > that you think may be useful for others. > > We should probably add some documentation for them and re-run and > ship the m3tohtml results to the web server, but that can be done > later. > > Thanks for your contributions, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 Would it be useful to dual-licence new code under the LGPL(2 or later) on the remote chance that other parts of Modula 3 might someday also be so licenced. Or, for that matter, that someone might want to translate it to another language, by hand or otherwise? That would then be a derived work, also LGPL-able. Just trying to reduce future barriers to interoperation. -- hendrik > From dabenavidesd at yahoo.es Wed Nov 23 17:08:55 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 16:08:55 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111123151833.GA13397@topoi.pooq.com> Message-ID: <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> Hi all: if one were to rework MODULES INTERFACEs IMHO yes, would be useful, anyway, that should make no harm other's code (when appropitely veryfied at elast in ESC/Modula-3), when developing enough of libm3. A Short term could be m3core RT INTERFACES as they developed as a standard Modula-3, which they declare "free to use and implement". I however don't know about other's companies codes, since they could offer just that for their purposes, but that's less central of the issue. For instance linking other FOSS could be approved by that change in order to break down even further dependence. Inthe other side, DEC-SRC licence is pretty liberal, so it could be thought as GPL-compatible, which means that the same license is able to cope with the FOSS definitions, even that of FSF. Thanks in advance --- El mi?, 23/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 23 de noviembre, 2011 10:18 > On Wed, Nov 23, 2011 at 10:53:18AM > +0100, Olaf Wagner wrote: > > Hi Rodney, > > > > sorry for answering so late. > > > > Quoting "Rodney M. Bates" : > > > > >Olaf, is there a place in the elego-hosted > repositories I can put this? > > >I don't find it already present in my local copy > of cm3. > > >Can I create a new subdirectory, say in > cm3/m3-tools? > > > > Of course, just cvs-add it. Please make sure that it > compiles though. > > > > >On this topic, I have a few library packages that > might be useful > > >to somebody someday. Would Elegosoft be > interested in hosting them? > > > > As long as you don't upload gigabytes of M3 source > code (let us know > > of that in advance :-), please feel free to add and > share any library > > that you think may be useful for others. > > > > We should probably add some documentation for them and > re-run and > > ship the m3tohtml results to the web server, but that > can be done > > later. > > > > Thanks for your contributions, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > Would it be useful to dual-licence new code under the > LGPL(2 or later) > on the remote chance that other parts of Modula 3 might > someday also be > so licenced. Or, for that matter, that someone might > want to translate > it to another language, by hand or otherwise? That > would then be a > derived work, also LGPL-able. > > Just trying to reduce future barriers to interoperation. > > -- hendrik > > > > From vintagecoder at aol.com Wed Nov 23 17:19:57 2011 From: vintagecoder at aol.com (vintagecoder at aol.com) Date: Wed, 23 Nov 2011 16:19:57 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <20111123151833.GA13397@topoi.pooq.com> Message-ID: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> > Would it be useful to dual-licence new code under the LGPL(2 or later) on > the remote chance that other parts of Modula 3 might someday also be so > licenced. Or, for that matter, that someone might want to translate it > to another language, by hand or otherwise? That would then be a derived > work, also LGPL-able. The Critical Mass license is perfectly fine. What is the sick fascination with GPL? Why can't people just leave things alone and not try to force other people to live according to their rules. LGPL is just a slippery slope. > Just trying to reduce future barriers to interoperation. Really? The GPL never reduced any barriers. It is *all about* barriers. You truly want to reduce future barriers? Then public-domain your code or use a BSD or MIT license. Or just use the Critical Mass license and stop trying to turn everything into Linux. From dabenavidesd at yahoo.es Wed Nov 23 17:51:13 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 16:51:13 +0000 (GMT) Subject: [M3devel] m2tom3 Message-ID: <1322067073.72825.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: In fact the bottom line is how we can create an environment enough capable of hosting several languages or at least enough easy to develop cross compilers from Pascal, Modula-2 and Simula like languages for the benefit of those interested in porting legacy applications in a Modern of the day SOTA programming system with high performance and still easy deployment, which is hard to find this days on other platforms even to older or new systems ranging from CDC and Algol systems to embedded platforms of the and a Code generation Interface for C-based languages, like Fail-Safe (IDL, see: http://www.yonezaki.cs.titech.ac.jp/Workshop/isss2003/slides/Suenaga.pdf ), or something like for SPIN's Cove, which is the best languages that could be safe enough to share RT structures with Modula-3, etc, else it has no point to re-implement those UNSAFE interfaces with C instead of Modula-3 code IMHO. Also as a way to allow further development in even that languages as well if so as needed. Thanks in advance --- El mi?, 23/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com, "Hendrik Boom" > Fecha: mi?rcoles, 23 de noviembre, 2011 11:08 > Hi all: > if one were to rework MODULES INTERFACEs IMHO yes, would be > useful, anyway, that should make no harm other's code (when > appropitely veryfied at elast in ESC/Modula-3), when > developing enough of libm3. A Short term could be > m3core RT INTERFACES as they developed as a standard > Modula-3, which they declare "free to use and implement". I > however don't know about other's companies codes, since they > could offer just that for their purposes, but that's less > central of the issue. For instance linking other FOSS could > be approved by that change in order to break down even > further dependence. > Inthe other side, DEC-SRC licence is pretty liberal, so it > could be thought as GPL-compatible, which means that > the same license is able to cope with the FOSS definitions, > even that of FSF. > Thanks in advance > > --- El mi?, 23/11/11, Hendrik Boom > escribi?: > > > De: Hendrik Boom > > Asunto: Re: [M3devel] m2tom3 > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 23 de noviembre, 2011 10:18 > > On Wed, Nov 23, 2011 at 10:53:18AM > > +0100, Olaf Wagner wrote: > > > Hi Rodney, > > > > > > sorry for answering so late. > > > > > > Quoting "Rodney M. Bates" : > > > > > > >Olaf, is there a place in the elego-hosted > > repositories I can put this? > > > >I don't find it already present in my local > copy > > of cm3. > > > >Can I create a new subdirectory, say in > > cm3/m3-tools? > > > > > > Of course, just cvs-add it. Please make sure that > it > > compiles though. > > > > > > >On this topic, I have a few library packages > that > > might be useful > > > >to somebody someday. Would Elegosoft > be > > interested in hosting them? > > > > > > As long as you don't upload gigabytes of M3 > source > > code (let us know > > > of that in advance :-), please feel free to add > and > > share any library > > > that you think may be useful for others. > > > > > > We should probably add some documentation for > them and > > re-run and > > > ship the m3tohtml results to the web server, but > that > > can be done > > > later. > > > > > > Thanks for your contributions, > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 > 2345 > > 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > > USt-IdNr: DE163214194 > > > > Would it be useful to dual-licence new code under the > > LGPL(2 or later) > > on the remote chance that other parts of Modula 3 > might > > someday also be > > so licenced. Or, for that matter, that someone > might > > want to translate > > it to another language, by hand or otherwise? > That > > would then be a > > derived work, also LGPL-able. > > > > Just trying to reduce future barriers to > interoperation. > > > > -- hendrik > > > > > > > > From dabenavidesd at yahoo.es Wed Nov 23 18:16:50 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 17:16:50 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> Message-ID: <1322068610.69293.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: a perfect example of compatibility is the DEC-SRC SRCCollector Interface inter with GNU C Boehm's Collector compatible interface: http://opensource.apple.com/source/gcc/gcc-5493/boehm-gc/doc/README.macros And that happened a long time before [1] DEC-SRC closing so they knew at least that it could be possible to compile (and inferring types)/link to interchange both collectors (fully capable and enough compatible interfaces to make GC-safe in both DEC-SRC Modula-3 and GNU C languages, where is the counterexample for what you say) flawlessly say in any environment. Thanks in advance [1] H.-J. Boehm and Z. Shao, ?Inferring Type Maps during Garbage Collection,? IN OOPSLA ?93 WORKSHOP ON MEMORY MANAGEMENT AND GARBAGE COLLECTION, 1993. --- El mi?, 23/11/11, vintagecoder at aol.com escribi?: > De: vintagecoder at aol.com > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 23 de noviembre, 2011 11:19 > > Would it be useful to > dual-licence new code under the LGPL(2 or later) on > > the remote chance that other parts of Modula 3 might > someday also be so > > licenced. Or, for that matter, that someone > might want to translate it > > to another language, by hand or otherwise? That > would then be a derived > > work, also LGPL-able. > > The Critical Mass license is perfectly fine. What is the > sick fascination > with GPL? Why can't people just leave things alone and not > try to force > other people to live according to their rules. LGPL is just > a slippery > slope. > > > Just trying to reduce future barriers to > interoperation. > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > You truly want to reduce future barriers? Then > public-domain your code or > use a BSD or MIT license. Or just use the Critical Mass > license and stop > trying to turn everything into Linux. > From dabenavidesd at yahoo.es Thu Nov 24 22:30:35 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 24 Nov 2011 21:30:35 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1322068610.69293.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <1322170235.80764.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: in fact we need to address surely in a near future since xds Development Environment system has DEC-SRC Modula-3 infrastructure for Modula-2, Oberon-2 mixable Modules project compatibility: http://www.excelsior-usa.com/xds.html This could of big help for a lot of good tools that have applied for Modula-3 type system R&D. So instead of thinking in license mess, we would be thinking in language mixing. About that they are thinking in releasing the source codes, perhaps, if Elego folks would show interest we could bring some of their tools. The bottom line of this is we would have same capabilities like CM3-IDE ability to navigate sources, so to have source to source transformations seemingly navigation and code generations capabilities (like for C in XDS system). I suggest we can make something for that, given the same structure of compilers, of course there is a lot of work, but we could do it, you are so great programmers. Thanks in advance --- El mi?, 23/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com, vintagecoder at aol.com > Fecha: mi?rcoles, 23 de noviembre, 2011 12:16 > Hi all: > a perfect example of compatibility is the DEC-SRC > SRCCollector Interface inter with GNU C Boehm's Collector > compatible interface: > http://opensource.apple.com/source/gcc/gcc-5493/boehm-gc/doc/README.macros > > And that happened a long time before [1] DEC-SRC closing so > they knew at least that it could be possible to compile (and > inferring types)/link to interchange both collectors (fully > capable and enough compatible interfaces to make GC-safe in > both DEC-SRC Modula-3 and GNU C languages, where is the > counterexample for what you say) flawlessly say in any > environment. > > Thanks in advance > > [1] H.-J. Boehm and Z. Shao, ?Inferring Type Maps during > Garbage Collection,? IN OOPSLA ?93 WORKSHOP ON MEMORY > MANAGEMENT AND GARBAGE COLLECTION, 1993. > > > --- El mi?, 23/11/11, vintagecoder at aol.com > > escribi?: > > > De: vintagecoder at aol.com > > > Asunto: Re: [M3devel] m2tom3 > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 23 de noviembre, 2011 11:19 > > > Would it be useful to > > dual-licence new code under the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might > > someday also be so > > > licenced. Or, for that matter, that > someone > > might want to translate it > > > to another language, by hand or otherwise? > That > > would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the > > sick fascination > > with GPL? Why can't people just leave things alone and > not > > try to force > > other people to live according to their rules. LGPL is > just > > a slippery > > slope. > > > > > Just trying to reduce future barriers to > > interoperation. > > > > Really? The GPL never reduced any barriers. It is > *all > > about* barriers. > > > > You truly want to reduce future barriers? Then > > public-domain your code or > > use a BSD or MIT license. Or just use the Critical > Mass > > license and stop > > trying to turn everything into Linux. > > > From hendrik at topoi.pooq.com Thu Nov 24 23:13:43 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 24 Nov 2011 17:13:43 -0500 Subject: [M3devel] licences, again In-Reply-To: <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> References: <20111123151833.GA13397@topoi.pooq.com> <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> Message-ID: <20111124221343.GA13709@topoi.pooq.com> On Wed, Nov 23, 2011 at 04:08:55PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > if one were to rework MODULES INTERFACEs IMHO yes, would be useful, anyway, that should make no harm other's code (when appropitely veryfied at elast in ESC/Modula-3), when developing enough of libm3. A Short term could be m3core RT INTERFACES as they developed as a standard Modula-3, which they declare "free to use and implement". I however don't know about other's companies codes, since they could offer just that for their purposes, but that's less central of the issue. For instance linking other FOSS could be approved by that change in order to break down even further dependence. I can't say I really understand this paragraph. > Inthe other side, DEC-SRC licence is pretty liberal, so it could be thought as GPL-compatible, which means that the same license is able to cope with the FOSS definitions, even that of FSF. Certainly, I'd like it to be compatible with GPL. But I've been told that the FSF considers the DEC-SRC licence incompatible with the GPL. -- hendrik From hendrik at topoi.pooq.com Thu Nov 24 23:24:20 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 24 Nov 2011 17:24:20 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> References: <20111123151833.GA13397@topoi.pooq.com> <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> Message-ID: <20111124222420.GB13709@topoi.pooq.com> On Wed, Nov 23, 2011 at 04:19:57PM +0000, vintagecoder at aol.com wrote: > > Would it be useful to dual-licence new code under the LGPL(2 or later) on > > the remote chance that other parts of Modula 3 might someday also be so > > licenced. Or, for that matter, that someone might want to translate it > > to another language, by hand or otherwise? That would then be a derived > > work, also LGPL-able. > > The Critical Mass license is perfectly fine. What is the sick fascination > with GPL? Just that a lot of free software *is* released inder the GPL, and it would be convenient to be compatible. > Why can't people just leave things alone and not try to force > other people to live according to their rules. LGPL is just a slippery > slope. > > > Just trying to reduce future barriers to interoperation. > > Really? The GPL never reduced any barriers. It is *all about* barriers. It's about limiting one's freedom to limit others' freedom. And that is a barrrier, right. But the way to bypass the barrier is to release code under multiple licences, the GPL or LGPL together with whatever licence you prefer. Potential users can then choose whichever licence suits them. > > You truly want to reduce future barriers? Then public-domain your code or > use a BSD or MIT license. Those licences would do, yes. I suspect they're compatible with both the SRC licence (which the CM licence is based on) and GPL (but can anyone confirm that?). > Or just use the Critical Mass license and stop > trying to turn everything into Linux. It's actually on Windows that it's a particular problem. It's usual to distribute binaries there. Most potential Windows users don't have their own software development tools and can only use prelinked binaries. It's on Posix systems such as Linux that we have less of a problem, because they usually come with adequate development tools. -- hendrik From dabenavidesd at yahoo.es Fri Nov 25 00:46:32 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 24 Nov 2011 23:46:32 +0000 (GMT) Subject: [M3devel] licences, again In-Reply-To: <20111124221343.GA13709@topoi.pooq.com> Message-ID: <1322178392.49293.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi: thanks for the message. Again I meant, that surely we could work out this by recording all libm3 libraries suddenly and then make the all library LGPL (as suggested by Richard Stallman) or whatever the Folks want. So, I guess the best approach is given that the DEC-SRC report declares Modula-3 free use and implement as stated there: ftp://ftp.hpl.hp.com/pub/dec/SRC/research-reports/SRC-052.pdf "The right to implement or use the Modula-3 language is unrestricted" Therefore as some libm3 INTERFACEs are part of that Language Definition as some in m3core (which should be all in m3core or in libm3 but not in both IMHO) we could code MODULEs an license them in again whatever folks want (or even on several license but carefully, as DEC-SRC did: ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/copyright.html ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/commercial.html ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/non_commercial.html But I think they are all exactly the same document, so clearly there is was ? outdated and error-prone documentation (the tittle is wrong anyway in the commercial.html file), BTW Elego has a broken link: http://modula3.elegosoft.com/cm3/doc/reference/license.html in http://modula3.elegosoft.com/rsrc/digital-license.html Finally the history tells they "recreated" the Commercial license, I guess this was related to the fact that Pine Creek Software left Modula-3 Business somewhere in the 1993 or so as I recall. So that could be the effect of that. Anyway the new license docs seem like '94 so would be good to see what is the status of the current license, and that's the reason RMS said this was not good for FSF, since I think they were talking about this before '94 Naturally someone should be able to tell what the heck is this all about, first non-commercial license, the first commercial one and the newest. There is a tool the did in DEC-SRC, we could have to look for that: http://www.lim.nl/monitor/hector.html p 22 see: http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-92.pdf Thanks in advance --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] licences, again > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:13 > On Wed, Nov 23, 2011 at 04:08:55PM > +0000, Daniel Alejandro Benavides D. wrote: > > Hi all: > > if one were to rework MODULES INTERFACEs IMHO yes, > would be useful, anyway, that should make no harm other's > code (when appropitely veryfied at elast in ESC/Modula-3), > when developing enough of libm3. A Short term could be > m3core RT INTERFACES as they developed as a standard > Modula-3, which they declare "free to use and implement". I > however don't know about other's companies codes, since they > could offer just that for their purposes, but that's less > central of the issue. For instance linking other FOSS could > be approved by that change in order to break down even > further dependence. > > I can't say I really understand this paragraph. > > > Inthe other side, DEC-SRC licence is pretty liberal, > so it could be thought as GPL-compatible, which means > that the same license is able to cope with the FOSS > definitions, even that of FSF. > > Certainly, I'd like it to be compatible with GPL. > > But I've been told that the FSF considers the DEC-SRC > licence > incompatible with the GPL. > > -- hendrik > From dabenavidesd at yahoo.es Fri Nov 25 01:41:33 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 25 Nov 2011 00:41:33 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <1322181693.78177.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi all: I knew that for instance OpenWatcom or Watcom by that time had written a piece of code with resemblance of Modula-3 I guess NT implementation so I guess as I recall I saw the DEC-SRC Copyright license for commercial product there but I can't get into it, I would need time to dig their sources if there is any still that has that license, see: http://en.wikipedia.org/wiki/Open_Watcom See dates match exactly before 1994 license change http://research.microsoft.com/pubs/64242/implementingcvs.pdf There is controversy with Debian and Fedora legal teams, which I don't care more than OpenWatcom compiler had Modula-3 based code in their time, so if they got that before 94 (in 93) I guess this is the the way to go to understand the legalese, or say that DEC granted its license in other licenses which is sort of the idea in the GPL case even if it is not adjusted to it. IF FSF wants to ask for their license I don't see any reason for preventing asking that for. Thanks in advance --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:24 > On Wed, Nov 23, 2011 at 04:19:57PM > +0000, vintagecoder at aol.com > wrote: > > > Would it be useful to dual-licence new code under > the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might someday also be so > > > licenced. Or, for that matter, that someone > might want to translate it > > > to another language, by hand or otherwise? > That would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the sick fascination > > with GPL? > > Just that a lot of free software *is* released inder the > GPL, and it > would be convenient to be compatible. > > > Why can't people just leave things alone and not try > to force > > other people to live according to their rules. LGPL is > just a slippery > > slope. > > > > > Just trying to reduce future barriers to > interoperation. > > > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > It's about limiting one's freedom to limit others' > freedom. And that > is a barrrier, right. But the way to bypass the > barrier is to release > code under multiple licences, the GPL or LGPL together with > whatever > licence you prefer. Potential users can then choose > whichever licence > suits them. > > > > You truly want to reduce future barriers? Then > public-domain your code or > > use a BSD or MIT license. > > Those licences would do, yes. I suspect they're > compatible with both > the SRC licence (which the CM licence is based on) and GPL > (but can > anyone confirm that?). > > > Or just use the Critical Mass license and stop > > trying to turn everything into Linux. > > It's actually on Windows that it's a particular > problem. It's usual to > distribute binaries there. Most potential Windows > users don't have > their own software development tools and can only use > prelinked > binaries. > > It's on Posix systems such as Linux that we have less of a > problem, > because they usually come with adequate development tools. > > -- hendrik > > From dabenavidesd at yahoo.es Fri Nov 25 04:28:22 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 25 Nov 2011 03:28:22 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <1322191702.57301.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi all: in fact i think MS has the anti-free software parade creating cells of users in Universities, because they see how dramatically Java ad many others like GNU and Linux and all projects are just sweeping them (sorry if the words sound strong but what it feels is like that) as much they sweep in the industry, well most of times, say 90%. That's why they tell the history of their concern of Copyrights, which somehow is a FSF concern too if that was the case with the Modula-3 gnu based tools I see (here MS uses the naive terms Author's rights), so the idea behind this is they feel "bad" if the copy proprietary software is shared and so the rest is history, bu the main threat could not been even that but the actual fact that in the "Cloud", or virtual networked environments we will need to find a way of obviating or bypass this regulations, since is useless there, sicne it will be bypassed anyway, even if you go today to a video site store you get music that would be paid for in some parts of the world but still free in others which is point-less anyway if so, but that depends in where you are going to access those things but if everything is virtual it senseless, since would one make virtual systsems in a X country prohibit if they serve in Y country, obiously not I guess! I remember in fact a tale about virtual system trying to control that you can't give a web page to another individual, which sorts of feels bad, you know, you can't show anybody a thing is you pay for (If I can find the reference I will share it). The antithesis was developed long before an Image-based Electronic Library [1], in AT&T Labs, where they associated for Copyright compliance efforts with Copyright Clearance Center CCC to ask the authors that didn't agree to allow photocopying their paper texts, to ask them directly if they might do so for their project. I imagine a similar thing for the new tools on the Virtual Networked environments, where you share code directly on the net and so get involved in those efforts is something that is making proprietary users to feel threatened by that if so, for instance we could really make a Copyright clearance of Modula-3 sources (but implicitly telling FSF that we can share with them if they want to share code with us as well, which they could need who knows as I believe there are network packages here and there for Linux, etc. in Modula-3) so FSF feels happier and might want to ask the sources in other licenses which I believe is what concerns them they would do easier. That's my little idea of the new computation era "issues". Thanks in advance. [1] G. A. Story, L. O?Gorman, D. Fox, L. L. Schaper, and H. V. Jagadish, ?The RightPages image-based electronic library for alerting and browsing,? Computer, vol. 25, pp. 17-26, Sep. 1992. --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:24 > On Wed, Nov 23, 2011 at 04:19:57PM > +0000, vintagecoder at aol.com > wrote: > > > Would it be useful to dual-licence new code under > the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might someday also be so > > > licenced. Or, for that matter, that someone > might want to translate it > > > to another language, by hand or otherwise? > That would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the sick fascination > > with GPL? > > Just that a lot of free software *is* released inder the > GPL, and it > would be convenient to be compatible. > > > Why can't people just leave things alone and not try > to force > > other people to live according to their rules. LGPL is > just a slippery > > slope. > > > > > Just trying to reduce future barriers to > interoperation. > > > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > It's about limiting one's freedom to limit others' > freedom. And that > is a barrrier, right. But the way to bypass the > barrier is to release > code under multiple licences, the GPL or LGPL together with > whatever > licence you prefer. Potential users can then choose > whichever licence > suits them. > > > > You truly want to reduce future barriers? Then > public-domain your code or > > use a BSD or MIT license. > > Those licences would do, yes. I suspect they're > compatible with both > the SRC licence (which the CM licence is based on) and GPL > (but can > anyone confirm that?). > > > Or just use the Critical Mass license and stop > > trying to turn everything into Linux. > > It's actually on Windows that it's a particular > problem. It's usual to > distribute binaries there. Most potential Windows > users don't have > their own software development tools and can only use > prelinked > binaries. > > It's on Posix systems such as Linux that we have less of a > problem, > because they usually come with adequate development tools. > > -- hendrik > > From vintagecoder at aol.com Sat Nov 26 19:35:45 2011 From: vintagecoder at aol.com (vintagecoder at aol.com) Date: Sat, 26 Nov 2011 18:35:45 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <201111261835.pAQIZofL030035@ims-m12.mx.aol.com> >> The Critical Mass license is perfectly fine. What is the sick fascination >> with GPL? >Just that a lot of free software *is* released inder the GPL, and it >would be convenient to be compatible. A lot of /Linux/ software has been infected by GPL's viral forcible open source license. BSD and MIT licenses existed before GPL, they are truly /free/ and open source licenses, and they are also compatible with the GPL (for me that compatibility is worth nothing). If you use the GPL you will contaminate the original DEC license and people who would have contributed or included your software in situations where BSD and MIT licenses are common and accepted but who don't like GPL (OpenBSD for a notable example) will have problems with it. I personally have a problem with it. I was very pleased to find CM3 and the SRC license and I would be very dissapointed if it was contaminated by the GPL in the future. If you are going for freedom, there are a few good choices and none of them are GPL. I cannot any reason other than politics for adding the GPL to a preexisting product. I sincerely hope elegosoft avoids this! >> Why can't people just leave things alone and not try to force >> other people to live according to their rules. LGPL is just a slippery >> slope. > > Just trying to reduce future barriers to interoperation. > >> Really? The GPL never reduced any barriers. It is *all about* barriers. > It's about limiting one's freedom to limit others' freedom. And that is > a barrrier, right. But the way to bypass the barrier is to release code > under multiple licences, the GPL or LGPL together with whatever licence > you prefer. Potential users can then choose whichever licence suits > them. Mixing and matching licenses doesn't help because the GPL adds restrictions that aren't present in true free open source licenses. If you feel it necessary to license, what is the reason? Do you want to maintain ownership and foster community participation? Then use BSD or MIT licenses which are compatible with any open source license. Do you want to make a political statement and jump on a bandwagon over a cliff to the point where many big operations won't touch your product for fear of having to expose their code? Choose GPL. The GPL is incompatible with most open source licenses because it is not free, it adds restrictions that other licenses don't have. I read recently MINIX had said they are attempting to build commercial support and demand for their OS and they found the BSD license a significant help in doing that. They said many potential customers object to the GPL. From a standpoint of true freedom /and/ possible commercial success the BSD and MIT style licenses seem so obviously superior to a viral forcible open source license, I just can't see why anybody would choose the GPL except for purely political reasons. It's self destructive. >> You truly want to reduce future barriers? Then public-domain your code or >> use a BSD or MIT license. >Those licences would do, yes. I suspect they're compatible with both >the SRC licence (which the CM licence is based on) and GPL (but can >anyone confirm that?). Yes, I can confirm they're compatible from GPL's standpoint. I don't know about the DEC/SRC license. >> Or just use the Critical Mass license and stop >> trying to turn everything into Linux. > It's actually on Windows that it's a particular problem. It's usual to > distribute binaries there. Most potential Windows users don't have their > own software development tools and can only use prelinked binaries. I understand Windows users are mostly stuck with prebuilt applications. I don't understand what licensing considerations have to do with that. If you use the SRC license does that have any effect on the executables? If so, how will adding code with other licenses whether BSD, MIT, or even GPL make anything simpler or change anything? If the CM3 runtime is included in the SRC license then that is the low bar, that is, you will only be able to add restrictions to it, not remove any. If the runtime is not included then I think it would be extremely unwise to encumber it any further. I feel it would be unwise to encumber it any further in any case. From dabenavidesd at yahoo.es Sat Nov 26 20:42:30 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 26 Nov 2011 19:42:30 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <201111261835.pAQIZofL030035@ims-m12.mx.aol.com> Message-ID: <1322336550.58691.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: If anyone working a networking tool uses a _DEC_ license why would you suggest asking they to release it in a different license if only that makes work with another package to _DEC_. Is their obligation to release that, according to the original license you can not ask them to release their sources in that other license so, unless you clear the _DEC_ license then it makes no sense to do that later, in that view it's necessary to ask them more than one time. So that makes the all idea of sub license not clever at all which is what others did. The point is whatever package uses Modula-3 will need that license. Does this feel fair? I say if you have another license (and commercial house like Pine Creek Software, or others as well), makes sense since you can actually give away your software or not (I say this because once we have the sources on a "cloud" term BTW rejected by myself and for once and all by RMS), will be given to anyone in a public "virtual network", so you can not ask them to release their packages in that other license if it is derivative or not see PM3. That's why I guess _DEC_ released it in the '94 as a pretty liberal to have just one. So we can have the idea of a "public cloud" and a private one in one and feel free to ask them to do so, anyway the DEC license doesn't prohibit linking against Modula-3 GPL libraries, or why is that lm is linked in Modula-3. You need to look at the facts and see that it can be licensed like that since it's your will to do so, but do your code need that is useless once again because it will bypassed anyway (is against that freedom you want). The world is not just one point, even in the "virtual networks", and everyone should be free to pass around software, that's the main "resource" of a society as RMS stays, is what creates a good society in which we can live in, even if you don't agree the arguments is clever enough to give it a try for such a society in digital terms this is free software and society around it that makes it if so. If none want that then it is pointless to ask the _DEC_ license to be free for RMS etc want that ever, as he did but was rejected by '88 to Olivetti, it is us who want that, theirs is their business to accept it or not (asking to give them the copyrights seems like they can change their license to whatever they like and I can't agree with that as well, as _DEC_ I think didn't agree to do in their time their efforts to do so). Indeed _DEC_ tried with '94 license, whatever it feels right now for FSF I don't know but I like more the idea of having 2 licenses, since it's us who want that change, but again, giving it two or three or more licenses makes no much sense for my point of view if anyone wants that, it is useless, that's the point of the unique '94 license, much more liberty that anyone can have (RMS before '94 denial is a show of that as well, I agree with you on that). Thanks in advance --- El s?b, 26/11/11, vintagecoder at aol.com escribi?: > De: vintagecoder at aol.com > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: s?bado, 26 de noviembre, 2011 13:35 > >> The Critical Mass license is > perfectly fine. What is the sick fascination > >> with GPL? > > >Just that a lot of free software *is* released inder > the GPL, and it > >would be convenient to be compatible. > > A lot of /Linux/ software has been infected by GPL's viral > forcible open > source license. BSD and MIT licenses existed before GPL, > they are truly > /free/ and open source licenses, and they are also > compatible with the GPL > (for me that compatibility is worth nothing). > > If you use the GPL you will contaminate the original DEC > license and > people who would have contributed or included your software > in situations > where BSD and MIT licenses are common and accepted but who > don't like GPL > (OpenBSD for a notable example) will have problems with it. > I personally > have a problem with it. I was very pleased to find CM3 and > the SRC license > and I would be very dissapointed if it was contaminated by > the GPL in the > future. > > If you are going for freedom, there are a few good choices > and none of them > are GPL. I cannot any reason other than politics for adding > the GPL to a > preexisting product. I sincerely hope elegosoft avoids > this! > > >> Why can't people just leave things alone and not > try to force > >> other people to live according to their rules. > LGPL is just a slippery > >> slope. > > > > Just trying to reduce future barriers to > interoperation. > > > >> Really? The GPL never reduced any barriers. It is > *all about* barriers. > > > It's about limiting one's freedom to limit others' > freedom. And that is > > a barrrier, right. But the way to bypass the > barrier is to release code > > under multiple licences, the GPL or LGPL together with > whatever licence > > you prefer. Potential users can then choose > whichever licence suits > > them. > > Mixing and matching licenses doesn't help because the GPL > adds restrictions > that aren't present in true free open source licenses. If > you feel it > necessary to license, what is the reason? Do you want to > maintain ownership > and foster community participation? Then use BSD or MIT > licenses which are > compatible with any open source license. Do you want to > make a political > statement and jump on a bandwagon over a cliff to the point > where many big > operations won't touch your product for fear of having to > expose their > code? Choose GPL. The GPL is incompatible with most open > source licenses > because it is not free, it adds restrictions that other > licenses don't have. > > I read recently MINIX had said they are attempting to build > commercial > support and demand for their OS and they found the BSD > license a > significant help in doing that. They said many potential > customers object > to the GPL. > > From a standpoint of true freedom /and/ possible commercial > success the BSD > and MIT style licenses seem so obviously superior to a > viral forcible open > source license, I just can't see why anybody would choose > the GPL except > for purely political reasons. It's self destructive. > > >> You truly want to reduce future barriers? Then > public-domain your code or > >> use a BSD or MIT license. > > >Those licences would do, yes. I suspect they're > compatible with both > >the SRC licence (which the CM licence is based on) and > GPL (but can > >anyone confirm that?). > > Yes, I can confirm they're compatible from GPL's > standpoint. I don't know > about the DEC/SRC license. > > >> Or just use the Critical Mass license and stop > >> trying to turn everything into Linux. > > > It's actually on Windows that it's a particular > problem. It's usual to > > distribute binaries there. Most potential > Windows users don't have their > > own software development tools and can only use > prelinked binaries. > > I understand Windows users are mostly stuck with prebuilt > applications. I > don't understand what licensing considerations have to do > with that. If you > use the SRC license does that have any effect on the > executables? If so, > how will adding code with other licenses whether BSD, MIT, > or even GPL make > anything simpler or change anything? If the CM3 runtime is > included in the > SRC license then that is the low bar, that is, you will > only be able to add > restrictions to it, not remove any. If the runtime is not > included then I > think it would be extremely unwise to encumber it any > further. I feel it > would be unwise to encumber it any further in any case. > > > > From mika at async.caltech.edu Thu Nov 3 02:39:30 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Nov 2011 18:39:30 -0700 Subject: [M3devel] Trying to set up on AMD64_LINUX Message-ID: <20111103013930.50EAE1A2080@async.async.caltech.edu> Ran into an error I don't recognize, any ideas, anyone? myriam5% cm3 -commands --- building in AMD64_LINUX --- cd AMD64_LINUX ignoring ../src/m3overrides rm .M3SHIP rm .M3OVERRIDES inhale libm3core.m3x new source -> compiling ThreadPThreadC.c gcc -gstabs+ -m64 -fPIC -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/POSIX -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/PTHREAD -I../src/C/Common -I../src/float/C99 -I../src/time/POSIX -c ../src/thread/PTHREAD/ThreadPThreadC.c new "ThreadPThreadC.o" -> archiving libm3core.a rm libm3core.a fgrep m3gcdefs /ufs/arpa/mika/cm3/pkg/m3core/AMD64_LINUX/.M3EXPORTS 2>/dev/null >/dev/null rm libm3core.a rm libm3core.a.sa rm libm3core.so rm libm3core.so.5 rm libm3core.exp ar crus libm3core.a hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMac hine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.m o Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo gcc -gstabs+ -m64 -fPIC -Wl,-z,now -Wl,-z,origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/ufs/arpa/mika/cm3/bin/../lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RT Tipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMachine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo Poly Basis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.mo Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo -lm -pthread /usr/bin/ld: ThreadPThreadC.o: relocation R_X86_64_PC32 against `ThreadPThread__SignalHandler' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make_lib => 1 librarian failed building: m3core Fatal Error: package build failed rm m3make.args cd .. % uname -a Linux noname5 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux From jay.krell at cornell.edu Thu Nov 3 03:16:18 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 02:16:18 +0000 Subject: [M3devel] Trying to set up on AMD64_LINUX In-Reply-To: <20111103013930.50EAE1A2080@async.async.caltech.edu> References: <20111103013930.50EAE1A2080@async.async.caltech.edu> Message-ID: Possible a gcc bug. Possibly related to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 Possible fix is to stop using attribte(hidden) and such, but really, they are good things. I can poke around later maybe. I think AMD64_LINUX is a relatively popular platform here. Try with a newer gcc/ld? Try removing this: #if __GNUC__ >= 4 #pragma GCC visibility push(hidden) #endif in ThreadPThreadC.c. if that works, let's keep it, but move stuff around. Like, maybe move void SignalHandler(int signo, siginfo_t *info, void *context); above it, or put another decoration on that. - Jay > To: m3devel at elegosoft.com > Date: Wed, 2 Nov 2011 18:39:30 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] Trying to set up on AMD64_LINUX > > Ran into an error I don't recognize, any ideas, anyone? > > myriam5% cm3 -commands > --- building in AMD64_LINUX --- > > cd AMD64_LINUX > ignoring ../src/m3overrides > > rm .M3SHIP > rm .M3OVERRIDES > inhale libm3core.m3x > > new source -> compiling ThreadPThreadC.c > gcc -gstabs+ -m64 -fPIC -I../src/unix/Common -I../src -I../src/Csupport/Common -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/common -I../src/runtime/POSIX -I../src/runtime/ex_frame -I../src/thread/Common -I../src/thread/PTHREAD -I../src/C/Common -I../src/float/C99 -I../src/time/POSIX -c ../src/thread/PTHREAD/ThreadPThreadC.c > > new "ThreadPThreadC.o" -> archiving libm3core.a > rm libm3core.a > fgrep m3gcdefs /ufs/arpa/mika/cm3/pkg/m3core/AMD64_LINUX/.M3EXPORTS 2>/dev/null >/dev/null > rm libm3core.a > rm libm3core.a.sa > rm libm3core.so > rm libm3core.so.5 > rm libm3core.exp > ar crus libm3core.a hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RTTipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMac > hine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo > DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo PolyBasis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.m > o Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo > gcc -gstabs+ -m64 -fPIC -Wl,-z,now -Wl,-z,origin -Bsymbolic -Wl,--fatal-warnings -Wl,-rpath,\$ORIGIN -Wl,-rpath,\$ORIGIN/../lib -Wl,--warn-common -Wl,-rpath,/ufs/arpa/mika/cm3/bin/../lib -shared -Wl,-soname,libm3core.so.5 -o libm3core.so.5 hand.o dtoa.o libgcc.o RTHooks.io RTHooks.mo RT0.io RT0.mo RuntimeError.io RuntimeError.mo Compiler.io Compiler.mo RTAllocator.io RTAllocator.mo RTAllocCnts.io RTAllocStats.io RTAllocStats.mo RTHeap.io RTHeap.mo RTHeapInfo.io RTHeapInfo.mo RTHeapMap.io RTHeapMap.mo RTHeapRep.io RTHeapRep.mo RTHeapStats.io RTHeapStats.mo RTCollector.io RTCollector.mo RTCollectorSRC.io RTWeakRef.io RTIO.io RTIO.mo RTIOc.o RTLinkerX.io RTLinker.io RTLinker.mo RTLinkerC.o RTDebug.io RTDebug.mo RTDebugC.o RTError.io RTError.mo RTException.io RTException.mo RTMapOp.io RTMapOp.mo RTMisc.io RTMisc.mo RTMiscC.o RTModule.io RTPacking.io RTPacking.mo RTParams.io RTParams.mo RTProcedure.io RTProcedure.mo RTProcess.io RTProcess.mo RTProcessC.o RTThread.io RTTipe.io RT > Tipe.mo RTType.io RTType.mo RTTypeFP.io RTTypeFP.mo RTTypeMap.io RTTypeMap.mo RTutils.io RTutils.mo RTHeapDebug.io RTHeapDebug.mo RTArgs.io RTHeapEvent.io RTProcedureSRC.io RTSignal.io RTStack.io RTTypeSRC.io RTOS.io RTMachine.io RTArgs.mo RTOS.mo RTPerfTool.io RTPerfTool.mo RTOSbrk.o RTSignalPrivate.io RTSignalC.o RTSignalC.io RTSignal.mo RTExFrame.mo RTStackC.o Thread.io ThreadF.io Scheduler.io SchedulerPosix.io ThreadInternal.io ThreadInternal.o MutexRep.io ThreadEvent.io ThreadPThread.io ThreadPThread.mo ThreadPThreadC.o WinBaseTypes.io WinDef.io WinDef.mo WinNT.io WinNT.mo UtimeC.o UnixC.o UnixLink.o Uexec.io Uexec.o Unetdb.io Unetdb.o Umman.o Ugrp.io Ugrp.o Uin.o Uugid.o Uuio.o Uutmp.o Usignal.o Upwd.o Uprocess.o Usignal.io Uconstants.o Uutmp.io Umman.io UstatC.o Uuio.io Upwd.io Uugid.io Uprocess.io Unix.io Unix.mo Utime.io Utypes.io Uerror.io Usched.io Usocket.io Usocket.o Ustat.io Udir.io UdirC.o Uin.io Cerrno.io Cstddef.io Cstdint.io Cstdlib.io CstdlibC.o Ctypes.io > M3toC.io M3toC.mo CerrnoC.o Cstring.io CstringC.o Cstdio.io CstdioC.o Csignal.io CsignalC.o Csetjmp.io BasicCtypes.io RealFloat.io LongFloat.io ExtendedFloat.io IEEESpecial.io IEEESpecial.mo Real.mo LongReal.mo Extended.mo DragonInt.io DragonInt.mo DragonT.io DragonT.mo Real.io LongReal.io Extended.io RealFloat.mo LongFloat.mo ExtendedFloat.mo RealRep.io LongRealRep.io FPU.io FPU.mo FloatMode.io FloatMode.mo FloatModeC.io FloatModeC.o Time.io Tick.io Date.io FmtTime.io FmtTime.mo TickPortable.mo TimePosix.io TimePosix.mo DatePosix.io DatePosix.mo DatePosixC.o TimePosixC.o CConvert.io CConvert.mo Convert.io Convert.mo String8.io String8.mo String16.io String16.mo Text.io Text.mo TextClass.io TextClass.mo TextLiteral.io TextLiteral.mo Text8.io Text8.mo Text8Short.io Text8Short.mo Text8CString.io Text8CString.mo Text16.io Text16.mo Text16Short.io Text16Short.mo TextSub.io TextSub.mo TextCat.io TextCat.mo TextConv.io TextConv.mo Fingerprint.io Fingerprint.mo Poly.io Poly.mo Poly > Basis.io PolyBasis.mo Main.io WeakRef.io WeakRef.mo WordRep.io Word.io LongRep.io Long.io Word.mo Long.mo Boolean.io Boolean.mo Char.io Char.mo Int32.io Int32.mo Int64.io Int64.mo Integer.io Integer.mo Longint.io Longint.mo Refany.io Refany.mo ASCII.io ASCII.mo WideChar.io WideChar.mo Unicode.io Unicode.mo Address.io Address.mo -lm -pthread > /usr/bin/ld: ThreadPThreadC.o: relocation R_X86_64_PC32 against `ThreadPThread__SignalHandler' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > make_lib => 1 > librarian failed building: m3core > Fatal Error: package build failed > rm m3make.args > cd .. > > % uname -a > Linux noname5 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 07:24:54 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 06:24:54 +0000 Subject: [M3devel] Target.i3/Target.m3 reduction? Message-ID: There is fairly little target-dependent-ness in our system, aside from the gcc code. I would like to reduce it. There are a few forms: There is dependency on word size. This I don't see removing any time soon, given that the front end does layout of records and computation of field offsets. There is dependency on jumpbuf size. We mostly know how to remove this, but have failed so far. The generated code should use alloca for the locals. (and even then, longer term, don't use setjmp/longjmp). We have these big arrays of targets, esp. in m3middle/src/Target.i3: PA32_HPUX, PA64_HPUX, PPC32_OPENBSD, PPC64_DARWIN, PPC_DARWIN, PPC_LINUX, ... Many of the dependencies are really per architecture or per kernel, not per architecture x kernel combination. So this almost-cross product seems dumb. Suggestions? There is dependency on endianness. This is what I'm really focusing on. I think this only matters for interop with C bitfields. We have no C bitfields in our system now. And the frontend and backend I think have to agree...oh, nevermind, I don't see that in parse.c > Aligned_procedures Just be safe and assume this is always false? Or it is a nice optimization on the common x86/AMD64 platforms? > First_readable_addr Just hardcode this as 4K? Instead of the slight optimization of setting it to 8K for SPARC? > Allow_packed_byte_aligned The safe value here is false. We set it to true only for x86/AMD64. I think true is probably safe for all architectures but older Alphas. ? > Setjmp This has the same value on platforms except VMS. We can maybe provide a portably-named wrapper? Maybe not, since this function is kind of special. I have to go.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Nov 3 07:50:21 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Nov 2011 23:50:21 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20111103055141.DE9FECC8A7@birch.elegosoft.com> References: <20111103055141.DE9FECC8A7@birch.elegosoft.com> Message-ID: <20111103065021.EC1341A2080@async.async.caltech.edu> Hi Jay, This does seem to have fixed the problem, as far as I can tell. Thanks as always. Mika Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 11/11/03 06:51:41 > >Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c > >Log message: > declare SignalHandler before pragma GCC visibility push(hidden), see if > it helps From jay.krell at cornell.edu Thu Nov 3 08:09:07 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 07:09:07 +0000 Subject: [M3devel] new CVS commit output? Message-ID: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v <-- Alpha64.common new revision: 1.4; previous revision: 1.3 cDebug turned on... $VAR1 = [ 'cm3/m3-sys/cminstall/src/config-no-install', 'ALPHA_LINUX', 'ALPHA_OPENBSD', 'Alpha64.common' ]; module - cm3 dir - path - files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX ALPHA_OPENBSD Alpha64.common id - 21684 Searching for log file index... found log file at 0.21684, now writing tmp files. Checking current dir against last dir. Current directory cm3/m3-sys/cminstall/src/config-no-install is last directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all commits done. format_lists(): cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. ARGV -> -d -m m3commit at elegosoft.com -s -M cm3 -f ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 08:28:01 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 07:28:01 +0000 Subject: [M3devel] CM3 on IA64? In-Reply-To: <1317708354.1319.2.camel@zx6000.hecnet.eu> References: <4E8A34A9.6070704@wickensonline.co.uk>, , <1317699760.16995.YahooMailClassic@web29708.mail.ird.yahoo.com>, , <1317708354.1319.2.camel@zx6000.hecnet.eu> Message-ID: 1) I didn't get the error you got, but I fixed it anyway. 2) Please try this: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-IA64_LINUX-d5.9.0-20111103.tgz Which is the output of ./boot1.py IA64_LINUX. 3) Can you help me update this code: #elif defined(__linux) #if defined(__i386) context->uc_mcontext.gregs[REG_EIP] #elif defined(__amd64) context->uc_mcontext.gregs[REG_RIP] #elif defined(__powerpc) context->uc_mcontext.uc_regs->gregs[PT_NIP] #elif defined(__arm__) context->uc_mcontext.arm_pc #elif defined(__alpha__) context->uc_mcontext.sc_pc #else #error unknown __linux target #endif You will hit this #error with that .tar.gz. or I guess please give me access to the machine, thank you. My ssh public key is attached. (I think it is time I generate new keys though..) Thank you, - Jay > Subject: RE: [M3devel] CM3 on IA64? > From: mark at wickensonline.co.uk > To: jay.krell at cornell.edu > CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com > Date: Tue, 4 Oct 2011 07:05:54 +0100 > > Jay, > > If you do ever feel like tackling the problem again I can give you > access to Alpha and IA64 OpenVMS boxes as required. > > Regards, Mark. > > On Tue, 2011-10-04 at 05:24 +0000, Jay K wrote: > > VMS is a more difficult port..except that it is approaching Posix > > these days. > > I had it far along, for Alpha. My system wasn't up to date wrt Posix > > features. > > Linux on IA64 should be very easy. > > > > - Jay > > > > > > > Date: Tue, 4 Oct 2011 04:42:40 +0100 > > > From: dabenavidesd at yahoo.es > > > To: m3devel at elegosoft.com; mark at wickensonline.co.uk > > > Subject: Re: [M3devel] CM3 on IA64? > > > > > > Hi all: > > > you might find surprisingly more clients for the same platform: > > > http://unix.derkeiler.com/Newsgroups/comp.os.vms/2004-03/0130.html > > > > > > In the news of Ken Olsen's obituary, they mentioned how DEC was not > > about micros, then it would explain some interest on the language in > > that, besides not too many Mainframes machine are build this days, I > > would certainly interested in to take a look about what it can do > > about in OpenVMS (a native port of threads for instance, could be > > interesting). I don't know any Mainframe OSes, would run this days, > > Linux. If OpenVMS has the sources for purchase, would they license > > freely to construct replicas, etc? The post sounds it may take it up > > to that point if people gets involved. Obviously IA64 is just another > > beast but who cares that matter right now. > > > OK, maybe there is that Modula-3 has its kind of EE, would you > > matter to ask what is that? > > > http://www.computer.org/portal/web/csdl/doi/10.1109/4236.991448 > > > > > > It could be that of DoD Generic Trusted Intermediaries GTI, which > > was constructed for among others Trusted Solaris and alike is related, > > But,the thing is who is using it right now or used it. > > > doi:10.1080/10658989709342533 > > > > > > Thanks in advance > > > > > > --- El lun, 3/10/11, Mark Wickens > > escribi?: > > > > > > > De: Mark Wickens > > > > Asunto: [M3devel] CM3 on IA64? > > > > Para: m3devel at elegosoft.com > > > > Fecha: lunes, 3 de octubre, 2011 17:18 > > > > Hi guys, > > > > > > > > Has anyone attempted a port of CM3 to Itanium > > > > architecture? > > > > I've recently installed gentoo on my ZX6000 and it's all > > > > running very nicely. > > > > My thoughts turned to what would be involved in getting > > > > Modula-3 running. > > > > > > > > Kind regards, Mark. > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: id_dsa.pub Type: application/octet-stream Size: 600 bytes Desc: not available URL: From michael.anderson at elegosoft.com Thu Nov 3 10:52:47 2011 From: michael.anderson at elegosoft.com (Michael Anderson) Date: Thu, 03 Nov 2011 10:52:47 +0100 Subject: [M3devel] new CVS commit output? In-Reply-To: References: Message-ID: <4EB2646F.6090704@elegosoft.com> Indeed. There is some extra debugging output to help me figure out a problem with path parsing in the cvs log/mailer scripts. I'll have that fixed up shortly. Sorry for the console spam. Mike Am 11/3/11 8:09 AM, schrieb Jay K: > > > > /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v > <-- Alpha64.common > new revision: 1.4; previous revision: 1.3 > cDebug turned on... > $VAR1 = [ > 'cm3/m3-sys/cminstall/src/config-no-install', > 'ALPHA_LINUX', > 'ALPHA_OPENBSD', > 'Alpha64.common' > ]; > > module - cm3 > dir - > path - > files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX > ALPHA_OPENBSD Alpha64.common > id - 21684 > Searching for log file index... found log file at 0.21684, now writing > tmp files. > Checking current dir against last dir. > Current directory cm3/m3-sys/cminstall/src/config-no-install is last > directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all > commits done. > format_lists(): > cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common > format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; > files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. > ARGV -> > -d > -m > m3commit at elegosoft.com > -s > -M > cm3 > -f > > > > ? > > - Jay -- Michael Anderson IT Services& Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 3 17:57:05 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Nov 2011 16:57:05 +0000 Subject: [M3devel] new CVS commit output? In-Reply-To: <4EB2646F.6090704@elegosoft.com> References: , <4EB2646F.6090704@elegosoft.com> Message-ID: No problem. I'm just making sure it is expected. - Jay Date: Thu, 3 Nov 2011 10:52:47 +0100 From: michael.anderson at elegosoft.com To: m3devel at elegosoft.com Subject: Re: [M3devel] new CVS commit output? Indeed. There is some extra debugging output to help me figure out a problem with path parsing in the cvs log/mailer scripts. I'll have that fixed up shortly. Sorry for the console spam. Mike Am 11/3/11 8:09 AM, schrieb Jay K: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/Alpha64.common,v <-- Alpha64.common new revision: 1.4; previous revision: 1.3 cDebug turned on... $VAR1 = [ 'cm3/m3-sys/cminstall/src/config-no-install', 'ALPHA_LINUX', 'ALPHA_OPENBSD', 'Alpha64.common' ]; module - cm3 dir - path - files - cm3/m3-sys/cminstall/src/config-no-install ALPHA_LINUX ALPHA_OPENBSD Alpha64.common id - 21684 Searching for log file index... found log file at 0.21684, now writing tmp files. Checking current dir against last dir. Current directory cm3/m3-sys/cminstall/src/config-no-install is last directory /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install -- all commits done. format_lists(): cm3/m3-sys/cminstall/src/config-no-install/:ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common format_names(): dir = cm3/m3-sys/cminstall/src/config-no-install/; files = ALPHA_LINUX:ALPHA_OPENBSD:Alpha64.common. ARGV -> -d -m m3commit at elegosoft.com -s -M cm3 -f ? - Jay -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Nov 4 08:30:10 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 04 Nov 2011 00:30:10 -0700 Subject: [M3devel] adding new target? Message-ID: <20111104073010.D20E21A2080@async.async.caltech.edu> Hi Jay, I know you have mentioned before that it's now "easy" to add a new target. I would like to add a target that is already mostly there, I think. The one I want is mipsel-linux. This is to run on an Asus RT-N16 router running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors and 128 MB of DRAM. First before you read this email, are there any instructions for what I'm trying to do anywhere, beyond your emails? I am using boot1.py as you suggested. What I did was the following (guesses all along): made a cm3.cfg which I called MIPSEL_LINUX and put in m3-sys/cminstall/src/config-no-install: :::: readonly TARGET = "MIPSEL_LINUX" % code generation target readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler SYSTEM_ASM = "as" % Assembler m3back_m32 = "" % -m32 not allowed include("MIPSEL.common") include("Linux.common") :::: where MIPSEL.common contains: :::: readonly TARGET_ARCH = "MIPS" readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } :::: Now I don't really know which of these strings are just arbitrary strings that I'm defining here and which of them have to match other things (and if so, what they have to match). In any case I'm doing something wrong because I do (on a FreeBSD4 machine)... ./boot1.py MIPSEL_LINUX which runs for a bit and eventually degenerates to gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log gmake: `libcpp.a' is up to date. cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log gmake: `s-modes' is up to date. gmake: `insn-config.h' is up to date. gmake: Nothing to be done for `m3cg'. --- building in FreeBSD4 --- new source -> compiling RTHooks.i3 ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic new source -> compiling RT0.i3 ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RT0.ic new source -> compiling RuntimeError.i3 ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 ... Mika From dabenavidesd at yahoo.es Fri Nov 4 17:28:29 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 16:28:29 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: <20111104073010.D20E21A2080@async.async.caltech.edu> Message-ID: <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> Hi all: Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false This is a must in terms of addresanility, besides others like the endianess or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: http://www.fortunecity.com/skyscraper/motorola/22/resume.htm ). At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: http://www.youtube.com/watch?v=WUfvvFD5tAA. I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): http://users.crocker.com/~hudson/hudson.html Thanks in advance --- El vie, 4/11/11, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: [M3devel] adding new target? > Para: m3devel at elegosoft.com > Fecha: viernes, 4 de noviembre, 2011 02:30 > Hi Jay, > > I know you have mentioned before that it's now "easy" to > add a new target. > I would like to add a target that is already mostly there, > I think. > The one I want is mipsel-linux. This is to run on an > Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz > MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any > instructions for what > I'm trying to do anywhere, beyond your emails? I am > using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { > "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { > "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just > arbitrary > strings that I'm defining here and which of them have to > match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a > FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > gmake CFLAGS="-g > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** > illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal > error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > > From jay.krell at cornell.edu Fri Nov 4 17:35:06 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 16:35:06 +0000 Subject: [M3devel] adding new target? In-Reply-To: <20111104073010.D20E21A2080@async.async.caltech.edu> References: <20111104073010.D20E21A2080@async.async.caltech.edu> Message-ID: Please put "32" in the name of the target? That's just preference/taste, not a requirement. > cd ../FreeBSD4-I386_FREEBSD We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. I realize that is also confusing. But it is how you can transition from the old target names to the new ones. > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 And then later on we probably confused .ic/.mc files for assembly source or vice versa. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. grep -r -i linux m3makefile *quake* or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? - Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 18:07:52 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 17:07:52 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: Message-ID: <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> Hi all: in that case, it isn't the LINUXLIBC6 a better name for these targets (at least in Debian 3.0 or so), I mean, not necessarily embedded speaking. And then what does it mean that is not more or less upward "compatibility". Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] adding new target? Para: "Mika Nystrom" , "m3devel" Fecha: viernes, 4 de noviembre, 2011 11:35 ?Please put "32" in the name of the target? That's just preference/taste, not a requirement. ? > cd ../FreeBSD4-I386_FREEBSD ?We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. ?I realize that is also confusing. But it is how you can transition from the old target names to the new ones. ? > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5? ? And then later on we probably confused .ic/.mc files for assembly source or vice versa.? ?See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. ?We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. ?grep -r -i linux m3makefile *quake*? or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? ?- Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 4 18:36:58 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 17:36:58 +0000 Subject: [M3devel] adding new target? In-Reply-To: <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> References: , <1320426472.72488.YahooMailClassic@web29701.mail.ird.yahoo.com> Message-ID: Eh, maybe. Maybe MIPS32EL_LINUXLIBC6. I'm really not familiar with the versions. I think prior to 6 wasn't glibc and >=6 is glibc, and it probably hasn't gone to 7. In which case, no. This is also a confusing name, because almost nobody knows what "libc6" implies. Consider that most users weren't around before. And even I'm not sure what it means. I do believe the kernel version is relevant here also. That 2.4 never had decent pthreads, never had NPTL. But Linux certainly has had pthreads since long before 2.6/NPTL. - Jay Date: Fri, 4 Nov 2011 17:07:52 +0000 From: dabenavidesd at yahoo.es To: mika at async.caltech.edu; m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] adding new target? Hi all: in that case, it isn't the LINUXLIBC6 a better name for these targets (at least in Debian 3.0 or so), I mean, not necessarily embedded speaking. And then what does it mean that is not more or less upward "compatibility". Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] adding new target? Para: "Mika Nystrom" , "m3devel" Fecha: viernes, 4 de noviembre, 2011 11:35 Please put "32" in the name of the target? That's just preference/taste, not a requirement. > cd ../FreeBSD4-I386_FREEBSD We got confused and are building a host=FreeBSD4 target=I386_FREEBSD backend. I realize that is also confusing. But it is how you can transition from the old target names to the new ones. > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 And then later on we probably confused .ic/.mc files for assembly source or vice versa. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/platforms.quake. We should error clearly for what you did. See also m3-sys/m3middle/src/Target.i3 and Target.m3. And for that matter. grep -r -i linux m3makefile *quake* or such. The only occurences are likely in m3core and libm3. But in general, missing support is supposed to error clearly. Even for what you did. Odd. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/src/m3makefile?rev=1.241;content-type=text%2Fplain readonly proc GNU_platform (x) is if Platform_info contains x return Platform_info{x} else error ("GNU platform is not known for \"" & x & "\"") return "unknown-unknown-unknown" end end I'm curious to see the start of the m3cc build -- it didn't error? This platform list is unfortunate, in that the information is duplicated here and in each target's configuration file. Ideally that wouldn't be the case. Are you running Linux 2.4 or 2.6? I was running "Tomato" on my MIPS router, and it was 2.4. This might be a small problem. Linux has had pthreads since long before 2.6/NPTL, but we didn't use them, and don't know if they work adequately. User threads ought to work, if get/set/make/swapcontext are in 2.4. I strongly suggest we introduce an alternate target, MIPS32_LINUX_USERTHREADS or MIPS32EL_LINUX_USERTHREADS or MIPSEL_LINUX_USERTHREADS. That is, I suggest "userthreads" be part of the target name. Or somesuch. Granted, people won't know what it means if they should pick it, and it might sound "good" to people and they'd pick it accidentally. Perhaps you should just hack m3core/.../m3makefile yourself to build for this platform. But that seems a bit gross. Maybe MIPSEL_LINUX24? - Jay > To: m3devel at elegosoft.com > Date: Fri, 4 Nov 2011 00:30:10 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] adding new target? > > Hi Jay, > > I know you have mentioned before that it's now "easy" to add a new target. > I would like to add a target that is already mostly there, I think. > The one I want is mipsel-linux. This is to run on an Asus RT-N16 router > running OpenWRT or DD-WRT. These devices have 500 MHz MIPS processors > and 128 MB of DRAM. > > First before you read this email, are there any instructions for what > I'm trying to do anywhere, beyond your emails? I am using boot1.py > as you suggested. > > What I did was the following (guesses all along): > > made a cm3.cfg which I called MIPSEL_LINUX and put in > m3-sys/cminstall/src/config-no-install: > > :::: > readonly TARGET = "MIPSEL_LINUX" % code generation target > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string for GNU > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > SYSTEM_ASM = "as" % Assembler > > m3back_m32 = "" % -m32 not allowed > > include("MIPSEL.common") > include("Linux.common") > :::: > > where MIPSEL.common contains: > > :::: > > readonly TARGET_ARCH = "MIPS" > readonly TARGET_ENDIAN = "LITTLE" % { "BIG" OR "LITTLE" } > readonly WORD_SIZE = "32BITS" % { "32BITS" or "64BITS" } > > :::: > > Now I don't really know which of these strings are just arbitrary > strings that I'm defining here and which of them have to match > other things (and if so, what they have to match). > > In any case I'm doing something wrong because I do (on a FreeBSD4 > machine)... > > ./boot1.py MIPSEL_LINUX > > which runs for a bit and eventually degenerates to > > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `libcpp.a' is up to date. > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > cd ../FreeBSD4-I386_FREEBSD && cd gcc && gmake CFLAGS="-g -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > m3cg | tee -a /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > gmake: `s-modes' is up to date. > gmake: `insn-config.h' is up to date. > gmake: Nothing to be done for `m3cg'. > --- building in FreeBSD4 --- > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > ... > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Nov 4 18:39:19 2011 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Nov 2011 17:39:19 +0000 Subject: [M3devel] adding new target? In-Reply-To: <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> References: <20111104073010.D20E21A2080@async.async.caltech.edu>, <1320424109.97115.YahooMailClassic@web29709.mail.ird.yahoo.com> Message-ID: > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. - Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 19:08:29 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 18:08:29 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: Message-ID: <1320430109.66209.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: well, but nonetheless, like first DEC pdp-10 didn't have those: http://www.xkl.com/darkstar.html Even today I doubt modern pdp-10 would have it or not, maybe I guess. In retrospective you sort of fell like you could build your own OS for those big machines, even now, why wouldn't one think the same way. I think they even created paging hardware and basically the same sort of handling would depend on the OS itself as well to handle it (they had ported some Unix from AT&T and BSD of historic value but I don't know even a Linux distro that runs on it or something like that, well maybe some emulator). http://en.wikipedia.org/wiki/SIMH#Digital_Equipment_Corporation The interest on this stuff is the packet fields and BITS types of Modula-3, wouldn't be nice to have those on a recent hardware implementations? But then we would need to address the INTEGER issues, and etc (p.d they have ported gcc to there, so this is fact possible: http://gcc.gnu.org/ml/gcc/2008-04/msg00516.html ) Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] adding new target? Para: dabenavidesd at yahoo.es, "m3devel" , "Mika Nystrom" Fecha: viernes, 4 de noviembre, 2011 12:39 > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. ?- Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Nov 4 23:31:52 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Nov 2011 22:31:52 +0000 (GMT) Subject: [M3devel] adding new target? In-Reply-To: <1320430109.66209.YahooMailClassic@web29707.mail.ird.yahoo.com> Message-ID: <1320445912.67026.YahooMailClassic@web29713.mail.ird.yahoo.com> Hi all: in fact there are even new hardware hacks for that as well, someones in practice: http://homepage.mac.com/dgcx/pdp10x/ http://www.freak-search.com/en/thread/3102486/its_starting_to_be_a_pdp-10 Besides that I think the Thread implementation on SRC Modula-3 used to depend on an instruction that the Pdp-10 could execute so we can afford to compete one of those beasts with modern ones to see real and emulated performance, if one such DECiestis interested: http://www.webservertalk.com/archive154-2006-5-1505344.html I would host on of those, but how much power does it consume, very angry machine, although important steps for history of Computation, maybe in a virtual museum :) https://www.msu.edu/~mrr/mycomp/cdc6000/cdc_emulators.htm Thanks in advance --- El vie, 4/11/11, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] adding new target? Para: "m3devel" , "Mika Nystrom" , "Jay K" Fecha: viernes, 4 de noviembre, 2011 13:08 Hi all: well, but nonetheless, like first DEC pdp-10 didn't have those: http://www.xkl.com/darkstar.html Even today I doubt modern pdp-10 would have it or not, maybe I guess. In retrospective you sort of fell like you could build your own OS for those big machines, even now, why wouldn't one think the same way. I think they even created paging hardware and basically the same sort of handling would depend on the OS itself as well to handle it (they had ported some Unix from AT&T and BSD of historic value but I don't know even a Linux distro that runs on it or something like that, well maybe some emulator). http://en.wikipedia.org/wiki/SIMH#Digital_Equipment_Corporation The interest on this stuff is the packet fields and BITS types of Modula-3, wouldn't be nice to have those on a recent hardware implementations? But then we would need to address the INTEGER issues, and etc (p.d they have ported gcc to there, so this is fact possible: http://gcc.gnu.org/ml/gcc/2008-04/msg00516.html ) Thanks in advance --- El vie, 4/11/11, Jay K escribi?: De: Jay K Asunto: RE: [M3devel] adding new target? Para: dabenavidesd at yahoo.es, "m3devel" , "Mika Nystrom" Fecha: viernes, 4 de noviembre, 2011 12:39 > does this MIPS have MMU-less chipI doubt it, but maybe. I think even routers are "big" systems with MMUs. ?- Jay > Date: Fri, 4 Nov 2011 16:28:29 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; mika at async.caltech.edu > Subject: Re: [M3devel] adding new target? > > Hi all: > Does this MIPS have MMU-less chip, meaning, there are embedded linuses that run it: > http://books.google.com/books?id=kk8G2gK4Tw8C&lpg=PA48&ots=c_1Nl4KtOw&dq=%22MMu-less%22%20mips&pg=PA49#v=onepage&q&f=false > > This is a must in terms of addresanility, besides others like the endianess > or sort for DS3100, etc re-configurable (weel not in hot but at driver level, like in SPARC: > > http://www.fortunecity.com/skyscraper/motorola/22/resume.htm > ). > > At the bottom of this and newer SMp there are issues as in Intel, that might be need to be put in consideration for gcc or so: > http://www.youtube.com/watch?v=WUfvvFD5tAA. > > I don't know maybe that gcc for gnu/m3 was not a bad idea at all (fsf isn't helping that as well too much): > http://users.crocker.com/~hudson/hudson.html > > Thanks in advance > > --- El vie, 4/11/11, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: [M3devel] adding new target? > > Para: m3devel at elegosoft.com > > Fecha: viernes, 4 de noviembre, 2011 02:30 > > Hi Jay, > > > > I know you have mentioned before that it's now "easy" to > > add a new target. > > I would like to add a target that is already mostly there, > > I think. > > The one I want is mipsel-linux. This is to run on an > > Asus RT-N16 router > > running OpenWRT or DD-WRT. These devices have 500 MHz > > MIPS processors > > and 128 MB of DRAM. > > > > First before you read this email, are there any > > instructions for what > > I'm trying to do anywhere, beyond your emails? I am > > using boot1.py > > as you suggested. > > > > What I did was the following (guesses all along): > > > > made a cm3.cfg which I called MIPSEL_LINUX and put in > > m3-sys/cminstall/src/config-no-install: > > > > :::: > > readonly TARGET = "MIPSEL_LINUX" % code generation target > > readonly GNU_PLATFORM = "mipsel-linux" % "cpu-os" string > > for GNU > > > > SYSTEM_CC = "gcc -gstabs+ -fPIC" % C compiler > > SYSTEM_ASM = "as" % Assembler > > > > m3back_m32 = "" % -m32 not allowed > > > > include("MIPSEL.common") > > include("Linux.common") > > :::: > > > > where MIPSEL.common contains: > > > > :::: > > > > readonly TARGET_ARCH = "MIPS" > > readonly TARGET_ENDIAN = "LITTLE" % { > > "BIG" OR "LITTLE" } > > readonly WORD_SIZE = "32BITS" % { > > "32BITS" or "64BITS" } > > > > :::: > > > > Now I don't really know which of these strings are just > > arbitrary > > strings that I'm defining here and which of them have to > > match > > other things (and if so, what they have to match). > > > > In any case I'm doing something wrong because I do (on a > > FreeBSD4 > > machine)... > > > > ./boot1.py MIPSEL_LINUX > > > > which runs for a bit and eventually degenerates to > > > > gmake[1]: Nothing to be done for `all'. > > gmake[1]: Leaving directory > > `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-I386_FREEBSD/libdecnumber' > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd libcpp && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: libcpp.a | tee -a > > > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `libcpp.a' is up to date. > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > cd ../FreeBSD4-I386_FREEBSD && cd gcc && > > gmake CFLAGS="-g > > -O2" MAKE=gmake AUTOCONF=: AUTOMAKE=: > > LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h > > m3cg | tee -a > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/../FreeBSD4-I386_FREEBSD/_m3.log > > gmake: `s-modes' is up to date. > > gmake: `insn-config.h' is up to date. > > gmake: Nothing to be done for `m3cg'. > > --- building in FreeBSD4 --- > > > > new source -> compiling RTHooks.i3 > > ../src/runtime/common/RTHooks.i3:15: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RTHooks.ic > > new source -> compiling RT0.i3 > > ../src/runtime/common/RT0.i3:19: fatal error: *** > > illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > m3cc (aka cm3cg) failed compiling: RT0.ic > > new source -> compiling RuntimeError.i3 > > ../src/runtime/common/RuntimeError.i3:10: fatal > > error: *** illegal type: 0x6f, at m3cg_lineno 5 > > compilation terminated. > > m3_backend => 1 > > ... > > > > Mika > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Tue Nov 15 23:44:17 2011 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 15 Nov 2011 22:44:17 +0000 Subject: [M3devel] m2tom3 Message-ID: <4EC2EB41.6010203@wickensonline.co.uk> Guys, I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz I attempted to compile it using cm3, but I get an unknown interface: msw at x60:~/m2tom3/m2tom3/src$ cm3 --- building in ../LINUXLIBC6 --- unsupported m3_option value: "-O" new source -> compiling Standard.m3 "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) 1 error encountered compilation failed => not building program "m2tom3" Fatal Error: package build failed Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. Regards, Makr. From rcolebur at SCIRES.COM Wed Nov 16 00:17:33 2011 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 15 Nov 2011 18:17:33 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: Mark: I seem to recall that "TextF" was for "Text Friends" and that it was removed after Critical Mass changed the underlying TEXT representation to deal with the new wide character sets. Here is a link that describes it a bit more: http://modula3.elegosoft.com/cm3/about-cm3.html#if-changes So, you will need to recode any operations that used the old TextF interface. If you want, I'll look around and see if I have an old copy of TextF laying around that you can review to see what code you will need to implement. I don't think it will be too much work. Let me know if you need it. Perhaps someone else on this thread has already done something along these lines. Regards, Randy Coleburn -----Original Message----- From: Mark Wickens [mailto:mark at wickensonline.co.uk] Sent: Tuesday, November 15, 2011 5:44 PM To: m3devel Subject: [M3devel] m2tom3 Guys, I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz I attempted to compile it using cm3, but I get an unknown interface: msw at x60:~/m2tom3/m2tom3/src$ cm3 --- building in ../LINUXLIBC6 --- unsupported m3_option value: "-O" new source -> compiling Standard.m3 "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) 1 error encountered compilation failed => not building program "m2tom3" Fatal Error: package build failed Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. Regards, Makr. From mika at async.caltech.edu Wed Nov 16 00:24:57 2011 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 15 Nov 2011 15:24:57 -0800 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <20111115232457.78E2C1A205B@async.async.caltech.edu> What I would do is: 1. delete IMPORT TextF 2. see what breaks, figure out the intent of the code, recode it using Text 3. check in the result to the CM3 repository so no one has to do it again! Mika Mark Wickens writes: >Guys, > >I found the m2tom3 translation utility here: >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >I attempted to compile it using cm3, but I get an unknown interface: > >msw at x60:~/m2tom3/m2tom3/src$ cm3 >--- building in ../LINUXLIBC6 --- > >unsupported m3_option value: "-O" >new source -> compiling Standard.m3 >"../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >1 error encountered >compilation failed => not building program "m2tom3" >Fatal Error: package build failed > > >Has anyone heard of interface TextF? Alternatively, is there a port of >this utility to cm3? > >I recently uncovered a machine-readable copy of my degree final year >project, a Meta Assembler, written in Modula-2, and wondered if I could >get it to compile using the utility to work with Modula-3. > >Regards, > >Makr. From dabenavidesd at yahoo.es Wed Nov 16 01:22:31 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 00:22:31 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111115232457.78E2C1A205B@async.async.caltech.edu> Message-ID: <1321402951.28257.YahooMailClassic@web29714.mail.ird.yahoo.com> Hi all: yeah my fault, but as I recall although I could compile this years ago, the main issue is that it didn't even work to feed the file to compile or so failed in therefore the first character was read. So it never worked for real for me. My best bet would export a SUN Unix syscall interface (since it tailored the SUN Modula-2 library) spec like Sphinx in SPIN OS so an export of it for every Modula-3 program understands itself right (yeah it coudl take the years spent from when I compiled until today, or so). If I were to start a new project perhaps would start making Unix legacy and updated replacements. The other approach perhaps the most indicated is just to wrap C on SPIN code to make it user level server. This could make the thing (inf act there is FreeBSD server already there just miss several calls, but nonetheless is something there). BTW, I don' know which platform this compiler used to work, so the main point would be emulate the real sys calls, since they just emulated in Sun OS and Solaris, nothing more. This has a potential utility for another project that depends on this m2tom3 tool. Thanks in advance --- El mar, 15/11/11, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 18:24 > What I would do is: > > 1. delete IMPORT TextF > 2. see what breaks, figure out the intent of the code, > recode it using Text > 3. check in the result to the CM3 repository so no one has > to do it again! > > Mika > > Mark Wickens writes: > >Guys, > > > >I found the m2tom3 translation utility here: > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > >I attempted to compile it using cm3, but I get an > unknown interface: > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > >--- building in ../LINUXLIBC6 --- > > > >unsupported m3_option value: "-O" > >new source -> compiling Standard.m3 > >"../src/Analyzer/Standard.m3", line 25: unable to find > interface (TextF) > >1 error encountered > >compilation failed => not building program "m2tom3" > >Fatal Error: package build failed > > > > > >Has anyone heard of interface TextF? Alternatively, is > there a port of > >this utility to cm3? > > > >I recently uncovered a machine-readable copy of my > degree final year > >project, a Meta Assembler, written in Modula-2, and > wondered if I could > >get it to compile using the utility to work with > Modula-3. > > > >Regards, > > > >Makr. > From dabenavidesd at yahoo.es Wed Nov 16 02:22:35 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 01:22:35 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321402951.28257.YahooMailClassic@web29714.mail.ird.yahoo.com> Message-ID: <1321406555.89220.YahooMailClassic@web29720.mail.ird.yahoo.com> Hi all: just forget that, it's done, the only thing we need is the SUN Modula-2 compilers, and that's all folks :) http://homepage.mac.com/dr2chase/resume.html How enough hard this men worked but how much good fellows they were (I can't see anything like this today in industry). Thanks in advance --- El mar, 15/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 19:22 > Hi all: > yeah my fault, but as I recall although I could compile > this years ago, the main issue is that it didn't even work > to feed the file to compile or so failed in therefore the > first character was read. So it never worked for real for > me. > My best bet would export a SUN Unix syscall interface > (since it tailored the SUN Modula-2 library) spec like > Sphinx in SPIN OS so an export of it for every Modula-3 > program understands itself right (yeah it coudl take the > years spent from when I compiled until today, or so). > If I were to start a new project perhaps would start making > Unix legacy and updated replacements. > The other approach perhaps the most indicated is just to > wrap C on SPIN code to make it user level server. This could > make the thing (inf act there is FreeBSD server already > there just miss several calls, but nonetheless is something > there). > BTW, I don' know which platform this compiler used to work, > so the main point would be emulate the real sys calls, since > they just emulated in Sun OS and Solaris, nothing more. This > has a potential utility for another project that depends on > this m2tom3 tool. > Thanks in advance > > --- El mar, 15/11/11, Mika Nystrom > escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 18:24 > > What I would do is: > > > > 1. delete IMPORT TextF > > 2. see what breaks, figure out the intent of the > code, > > recode it using Text > > 3. check in the result to the CM3 repository so no one > has > > to do it again! > > > > Mika > > > > Mark Wickens writes: > > >Guys, > > > > > >I found the m2tom3 translation utility here: > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > >I attempted to compile it using cm3, but I get an > > unknown interface: > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > >--- building in ../LINUXLIBC6 --- > > > > > >unsupported m3_option value: "-O" > > >new source -> compiling Standard.m3 > > >"../src/Analyzer/Standard.m3", line 25: unable to > find > > interface (TextF) > > >1 error encountered > > >compilation failed => not building program > "m2tom3" > > >Fatal Error: package build failed > > > > > > > > >Has anyone heard of interface TextF? > Alternatively, is > > there a port of > > >this utility to cm3? > > > > > >I recently uncovered a machine-readable copy of > my > > degree final year > > >project, a Meta Assembler, written in Modula-2, > and > > wondered if I could > > >get it to compile using the utility to work with > > Modula-3. > > > > > >Regards, > > > > > >Makr. > > > From dabenavidesd at yahoo.es Wed Nov 16 20:56:59 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 16 Nov 2011 19:56:59 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321406555.89220.YahooMailClassic@web29720.mail.ird.yahoo.com> Message-ID: <1321473419.50950.YahooMailClassic@web29720.mail.ird.yahoo.com> Hi all: I think this is the way to get out of this "moral-technical" issue with the Unix interfaces, so get back to the old style (of course not brutal cross product), though we could that for the sake of further compatibility (it should be transparent ideally, like an Universal VM), but compiled natively (DEC SRC had the Ultrix VAX API as well, so for vax, openVMS you could do that surely). And at the end just EXPORT Unix.System() or UnixV, UnixVI, etc and that's all. OK, let me know, thanks in advance --- El mar, 15/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: martes, 15 de noviembre, 2011 20:22 > Hi all: > just forget that, it's done, the only thing we need is the > SUN Modula-2 compilers, and that's all folks :) > http://homepage.mac.com/dr2chase/resume.html > > How enough hard this men worked but how much good fellows > they were (I can't see anything like this today in > industry). > > Thanks in advance > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > escribi?: > > > De: Daniel Alejandro Benavides D. > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" , > "Mika Nystrom" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 19:22 > > Hi all: > > yeah my fault, but as I recall although I could > compile > > this years ago, the main issue is that it didn't even > work > > to feed the file to compile or so failed in therefore > the > > first character was read. So it never worked for real > for > > me. > > My best bet would export a SUN Unix syscall interface > > (since it tailored the SUN Modula-2 library) spec > like > > Sphinx in SPIN OS so an export of it for every > Modula-3 > > program understands itself right (yeah it coudl take > the > > years spent from when I compiled until today, or so). > > If I were to start a new project perhaps would start > making > > Unix legacy and updated replacements. > > The other approach perhaps the most indicated is just > to > > wrap C on SPIN code to make it user level server. This > could > > make the thing (inf act there is FreeBSD server > already > > there just miss several calls, but nonetheless is > something > > there). > > BTW, I don' know which platform this compiler used to > work, > > so the main point would be emulate the real sys calls, > since > > they just emulated in Sun OS and Solaris, nothing > more. This > > has a potential utility for another project that > depends on > > this m2tom3 tool. > > Thanks in advance > > > > --- El mar, 15/11/11, Mika Nystrom > > escribi?: > > > > > De: Mika Nystrom > > > Asunto: Re: [M3devel] m2tom3 > > > Para: "Mark Wickens" > > > CC: m3devel at elegosoft.com > > > Fecha: martes, 15 de noviembre, 2011 18:24 > > > What I would do is: > > > > > > 1. delete IMPORT TextF > > > 2. see what breaks, figure out the intent of the > > code, > > > recode it using Text > > > 3. check in the result to the CM3 repository so > no one > > has > > > to do it again! > > > > > > Mika > > > > > > Mark Wickens writes: > > > >Guys, > > > > > > > >I found the m2tom3 translation utility here: > > > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > >I attempted to compile it using cm3, but I > get an > > > unknown interface: > > > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > >--- building in ../LINUXLIBC6 --- > > > > > > > >unsupported m3_option value: "-O" > > > >new source -> compiling Standard.m3 > > > >"../src/Analyzer/Standard.m3", line 25: > unable to > > find > > > interface (TextF) > > > >1 error encountered > > > >compilation failed => not building > program > > "m2tom3" > > > >Fatal Error: package build failed > > > > > > > > > > > >Has anyone heard of interface TextF? > > Alternatively, is > > > there a port of > > > >this utility to cm3? > > > > > > > >I recently uncovered a machine-readable copy > of > > my > > > degree final year > > > >project, a Meta Assembler, written in > Modula-2, > > and > > > wondered if I could > > > >get it to compile using the utility to work > with > > > Modula-3. > > > > > > > >Regards, > > > > > > > >Makr. > > > > > > From dabenavidesd at yahoo.es Thu Nov 17 04:36:56 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 17 Nov 2011 03:36:56 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1321473419.50950.YahooMailClassic@web29720.mail.ird.yahoo.com> Message-ID: <1321501016.42602.YahooMailClassic@web29709.mail.ird.yahoo.com> Hi all: and I see this: http://labs.oracle.com/forest/COM.Sun.Labs.Forest.doc.see_97.paper_pdf.pdf indicated that it was possible to either compile and cross-assemble or compile and run over its DEC-SRC Microkernel VMS code, at least at user-level. Anyway, the main thing here is that this cross-ports like SOLGnu or Darwin are actually possible to run in one compilation and two code generations. That is better functionality or at least I guess so for those platforms as well. Of course the idea would be run in SPIN, but in some cases like SPINE it can run actually NT386GNU and NT386 or for instance run in a LAN a NT_ALPHA_GNU (SPINE) and ALPHA_SPIN code almost instantly (like if it would an user-level server) alternatively or somehow a crazy thing like that in IX86 likewise setting. Thanks in advance --- El mi?, 16/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: "Mark Wickens" , "Mika Nystrom" > CC: m3devel at elegosoft.com > Fecha: mi?rcoles, 16 de noviembre, 2011 14:56 > Hi all: > I think this is the way to get out of this > "moral-technical" issue with the Unix interfaces, so get > back to the old style (of course not brutal cross product), > though we could that for the sake of further compatibility > (it should be transparent ideally, like an Universal VM), > but compiled natively (DEC SRC had the Ultrix VAX API as > well, so for vax, openVMS you could do that surely). > And at the end just EXPORT Unix.System() or UnixV, UnixVI, > etc and that's all. > OK, let me know, thanks in advance > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > escribi?: > > > De: Daniel Alejandro Benavides D. > > Asunto: Re: [M3devel] m2tom3 > > Para: "Mark Wickens" , > "Mika Nystrom" > > CC: m3devel at elegosoft.com > > Fecha: martes, 15 de noviembre, 2011 20:22 > > Hi all: > > just forget that, it's done, the only thing we need is > the > > SUN Modula-2 compilers, and that's all folks :) > > http://homepage.mac.com/dr2chase/resume.html > > > > How enough hard this men worked but how much good > fellows > > they were (I can't see anything like this today in > > industry). > > > > Thanks in advance > > > > --- El mar, 15/11/11, Daniel Alejandro Benavides D. > > > escribi?: > > > > > De: Daniel Alejandro Benavides D. > > > Asunto: Re: [M3devel] m2tom3 > > > Para: "Mark Wickens" , > > "Mika Nystrom" > > > CC: m3devel at elegosoft.com > > > Fecha: martes, 15 de noviembre, 2011 19:22 > > > Hi all: > > > yeah my fault, but as I recall although I could > > compile > > > this years ago, the main issue is that it didn't > even > > work > > > to feed the file to compile or so failed in > therefore > > the > > > first character was read. So it never worked for > real > > for > > > me. > > > My best bet would export a SUN Unix syscall > interface > > > (since it tailored the SUN Modula-2 library) > spec > > like > > > Sphinx in SPIN OS so an export of it for every > > Modula-3 > > > program understands itself right (yeah it coudl > take > > the > > > years spent from when I compiled until today, or > so). > > > If I were to start a new project perhaps would > start > > making > > > Unix legacy and updated replacements. > > > The other approach perhaps the most indicated is > just > > to > > > wrap C on SPIN code to make it user level server. > This > > could > > > make the thing (inf act there is FreeBSD server > > already > > > there just miss several calls, but nonetheless > is > > something > > > there). > > > BTW, I don' know which platform this compiler > used to > > work, > > > so the main point would be emulate the real sys > calls, > > since > > > they just emulated in Sun OS and Solaris, > nothing > > more. This > > > has a potential utility for another project that > > depends on > > > this m2tom3 tool. > > > Thanks in advance > > > > > > --- El mar, 15/11/11, Mika Nystrom > > > escribi?: > > > > > > > De: Mika Nystrom > > > > Asunto: Re: [M3devel] m2tom3 > > > > Para: "Mark Wickens" > > > > CC: m3devel at elegosoft.com > > > > Fecha: martes, 15 de noviembre, 2011 18:24 > > > > What I would do is: > > > > > > > > 1. delete IMPORT TextF > > > > 2. see what breaks, figure out the intent of > the > > > code, > > > > recode it using Text > > > > 3. check in the result to the CM3 repository > so > > no one > > > has > > > > to do it again! > > > > > > > > Mika > > > > > > > > Mark Wickens writes: > > > > >Guys, > > > > > > > > > >I found the m2tom3 translation utility > here: > > > > > > >http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > > >I attempted to compile it using cm3, but > I > > get an > > > > unknown interface: > > > > > > > > > >msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > > >--- building in ../LINUXLIBC6 --- > > > > > > > > > >unsupported m3_option value: "-O" > > > > >new source -> compiling Standard.m3 > > > > >"../src/Analyzer/Standard.m3", line 25: > > unable to > > > find > > > > interface (TextF) > > > > >1 error encountered > > > > >compilation failed => not building > > program > > > "m2tom3" > > > > >Fatal Error: package build failed > > > > > > > > > > > > > > >Has anyone heard of interface TextF? > > > Alternatively, is > > > > there a port of > > > > >this utility to cm3? > > > > > > > > > >I recently uncovered a machine-readable > copy > > of > > > my > > > > degree final year > > > > >project, a Meta Assembler, written in > > Modula-2, > > > and > > > > wondered if I could > > > > >get it to compile using the utility to > work > > with > > > > Modula-3. > > > > > > > > > >Regards, > > > > > > > > > >Makr. > > > > > > > > > > From rodney_bates at lcwb.coop Thu Nov 17 17:29:04 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Nov 2011 10:29:04 -0600 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <4EC53650.6070206@lcwb.coop> I have used m2tom3 successfully a couple of times in the (distant) past. There are a few places where the languages are different enough that you get either unidiomatic or unworkable translations. As I recall, the method of returning a function result will require some hand cleanup, and variant records, if you have them, will just be flattened, rather than converted to an object type hierarchy. Nevertheless, it will save a *lot* of tedious editing of mundane syntactic nits. TextF exposes PM3's internal representation of TEXT values, which is altogether different from that of CM3, so you will not be able to use it unless you use PM3. I am sure it is in the PM3 distribution at Elego, and I know I have copies around. By now, PM3 has probably suffered some bitrot, so installing it might take some work. I have an installation around on a machine that has not been powered up for a few months, but probably works. I probably also have a compiled executable for m2tom3 on LINUXLIBC6 that might run on a machine of that type. I could provide a copy of that, if you want to see if you can do it without putting in a lot of work. Or maybe I could just run it for you a few times. On 11/15/2011 04:44 PM, Mark Wickens wrote: > Guys, > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > I attempted to compile it using cm3, but I get an unknown interface: > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > --- building in ../LINUXLIBC6 --- > > unsupported m3_option value: "-O" > new source -> compiling Standard.m3 > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > 1 error encountered > compilation failed => not building program "m2tom3" > Fatal Error: package build failed > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > Regards, > > Makr. > > From rodney_bates at lcwb.coop Thu Nov 17 18:09:49 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Nov 2011 11:09:49 -0600 Subject: [M3devel] m2tom3 In-Reply-To: <4EC2EB41.6010203@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> Message-ID: <4EC53FDD.2040301@lcwb.coop> I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. The result is attached. It compiled and linked on AMD64_LINUX, and executed enough to give the help text and to translate a tiny bit of Modula-2 code. I'm biting my tongue on why it was coded this way in the first place. On 11/15/2011 04:44 PM, Mark Wickens wrote: > Guys, > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > I attempted to compile it using cm3, but I get an unknown interface: > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > --- building in ../LINUXLIBC6 --- > > unsupported m3_option value: "-O" > new source -> compiling Standard.m3 > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > 1 error encountered > compilation failed => not building program "m2tom3" > Fatal Error: package build failed > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > Regards, > > Makr. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Standard.m3 URL: From jay.krell at cornell.edu Thu Nov 17 18:57:53 2011 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Nov 2011 17:57:53 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <4EC53FDD.2040301@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk>,<4EC53FDD.2040301@lcwb.coop> Message-ID: Commit the initial version, and then the revisions, to the cm3 repository? - Jay > Date: Thu, 17 Nov 2011 11:09:49 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m2tom3 > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > The result is attached. > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > and to translate a tiny bit of Modula-2 code. > > I'm biting my tongue on why it was coded this way in the first place. > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > Guys, > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > I attempted to compile it using cm3, but I get an unknown interface: > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > --- building in ../LINUXLIBC6 --- > > > > unsupported m3_option value: "-O" > > new source -> compiling Standard.m3 > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > 1 error encountered > > compilation failed => not building program "m2tom3" > > Fatal Error: package build failed > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > Regards, > > > > Makr. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Thu Nov 17 19:40:37 2011 From: mark at wickensonline.co.uk (Mark Wickens) Date: Thu, 17 Nov 2011 18:40:37 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <4EC53FDD.2040301@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC55525.8010904@wickensonline.co.uk> On 17/11/11 17:09, Rodney M. Bates wrote: > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > by eliminating IMPORT TextF and changing 4 places from the form > TextVariable[j] > to Text.GetChar(TextVariable,j). This is file > m2tom3/src/Analyzer/Standard,m3. > The result is attached. > > It compiled and linked on AMD64_LINUX, and executed enough to give the > help text > and to translate a tiny bit of Modula-2 code. > > I'm biting my tongue on why it was coded this way in the first place. > > On 11/15/2011 04:44 PM, Mark Wickens wrote: >> Guys, >> >> I found the m2tom3 translation utility here: >> http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >> I attempted to compile it using cm3, but I get an unknown interface: >> >> msw at x60:~/m2tom3/m2tom3/src$ cm3 >> --- building in ../LINUXLIBC6 --- >> >> unsupported m3_option value: "-O" >> new source -> compiling Standard.m3 >> "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >> 1 error encountered >> compilation failed => not building program "m2tom3" >> Fatal Error: package build failed >> >> >> Has anyone heard of interface TextF? Alternatively, is there a port >> of this utility to cm3? >> >> I recently uncovered a machine-readable copy of my degree final year >> project, a Meta Assembler, written in Modula-2, and wondered if I >> could get it to compile using the utility to work with Modula-3. >> >> Regards, >> >> Makr. >> >> Thanks Rodney, My M3 skills aren't up to much - I'll give it a whirl later. Regards, Mark. From michael.anderson at elegosoft.com Fri Nov 18 10:31:31 2011 From: michael.anderson at elegosoft.com (Michael Anderson) Date: Fri, 18 Nov 2011 10:31:31 +0100 Subject: [M3devel] [elego Server Maintenance] Friday, 18.11.2011 20:30 CET Message-ID: <4EC625F3.6030100@elegosoft.com> Hello, On Friday, November 18 at 8:30 PM CET, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services& Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Fri Nov 18 18:11:04 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:11:04 -0600 Subject: [M3devel] m2tom3 Standard.m3, second try. In-Reply-To: <4EC56C22.4040005@wickensonline.co.uk> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> <4EC56C22.4040005@wickensonline.co.uk> Message-ID: <4EC691A8.7080200@lcwb.coop> Opps, sorry. That was the unmodified version. I seem to have two different subdirectories with m3tom3 in them. Try this one. On 11/17/2011 02:18 PM, Mark Wickens wrote: > On 17/11/11 17:09, Rodney M. Bates wrote: >> I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 >> by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] >> to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. >> The result is attached. >> >> It compiled and linked on AMD64_LINUX, and executed enough to give the help text >> and to translate a tiny bit of Modula-2 code. >> >> I'm biting my tongue on why it was coded this way in the first place. >> >> On 11/15/2011 04:44 PM, Mark Wickens wrote: >>> Guys, >>> >>> I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz >>> I attempted to compile it using cm3, but I get an unknown interface: >>> >>> msw at x60:~/m2tom3/m2tom3/src$ cm3 >>> --- building in ../LINUXLIBC6 --- >>> >>> unsupported m3_option value: "-O" >>> new source -> compiling Standard.m3 >>> "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) >>> 1 error encountered >>> compilation failed => not building program "m2tom3" >>> Fatal Error: package build failed >>> >>> >>> Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? >>> >>> I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. >>> >>> Regards, >>> >>> Makr. >>> >>> > Hi Rodney, is the version of Standard.m3 attached to your email the one you modified? > I can still see an import of TextF. > > Thanks for the help, > > Mark. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Standard.m3 URL: From rodney_bates at lcwb.coop Fri Nov 18 18:24:28 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:24:28 -0600 Subject: [M3devel] m2tom3 In-Reply-To: References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC694CC.1070004@lcwb.coop> Olaf, is there a place in the elego-hosted repositories I can put this? I don't find it already present in my local copy of cm3. Can I create a new subdirectory, say in cm3/m3-tools? On this topic, I have a few library packages that might be useful to somebody someday. Would Elegosoft be interested in hosting them? On 11/17/2011 11:57 AM, Jay K wrote: > Commit the initial version, and then the revisions, to the cm3 repository? > > - Jay > > Date: Thu, 17 Nov 2011 11:09:49 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m2tom3 > > > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > > The result is attached. > > > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > > and to translate a tiny bit of Modula-2 code. > > > > I'm biting my tongue on why it was coded this way in the first place. > > > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > > Guys, > > > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > I attempted to compile it using cm3, but I get an unknown interface: > > > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > --- building in ../LINUXLIBC6 --- > > > > > > unsupported m3_option value: "-O" > > > new source -> compiling Standard.m3 > > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > > 1 error encountered > > > compilation failed => not building program "m2tom3" > > > Fatal Error: package build failed > > > > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > > > Regards, > > > > > > Makr. > > > > > > From rodney_bates at lcwb.coop Fri Nov 18 18:25:22 2011 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Nov 2011 11:25:22 -0600 Subject: [M3devel] m2tom3 In-Reply-To: References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> Message-ID: <4EC69502.4050800@lcwb.coop> Olaf, is there a place in the elego-hosted repositories I can put this? I don't find it already present in my local copy of cm3. Can I create a new subdirectory, say in cm3/m3-tools or cm3/tools? On this topic, I have a few library packages that might be useful to somebody someday. Would Elegosoft be interested in hosting them? On 11/17/2011 11:57 AM, Jay K wrote: > Commit the initial version, and then the revisions, to the cm3 repository? > > - Jay > > Date: Thu, 17 Nov 2011 11:09:49 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] m2tom3 > > > > I dragged this out and, if a few minutes, got m2tom3 to compile under CM3 > > by eliminating IMPORT TextF and changing 4 places from the form TextVariable[j] > > to Text.GetChar(TextVariable,j). This is file m2tom3/src/Analyzer/Standard,m3. > > The result is attached. > > > > It compiled and linked on AMD64_LINUX, and executed enough to give the help text > > and to translate a tiny bit of Modula-2 code. > > > > I'm biting my tongue on why it was coded this way in the first place. > > > > On 11/15/2011 04:44 PM, Mark Wickens wrote: > > > Guys, > > > > > > I found the m2tom3 translation utility here: http://freepages.modula2.org/downloads/m2tom3-2.03.tar.gz > > > I attempted to compile it using cm3, but I get an unknown interface: > > > > > > msw at x60:~/m2tom3/m2tom3/src$ cm3 > > > --- building in ../LINUXLIBC6 --- > > > > > > unsupported m3_option value: "-O" > > > new source -> compiling Standard.m3 > > > "../src/Analyzer/Standard.m3", line 25: unable to find interface (TextF) > > > 1 error encountered > > > compilation failed => not building program "m2tom3" > > > Fatal Error: package build failed > > > > > > > > > Has anyone heard of interface TextF? Alternatively, is there a port of this utility to cm3? > > > > > > I recently uncovered a machine-readable copy of my degree final year project, a Meta Assembler, written in Modula-2, and wondered if I could get it to compile using the utility to work with Modula-3. > > > > > > Regards, > > > > > > Makr. > > > > > > From wagner at elegosoft.com Wed Nov 23 10:53:18 2011 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Nov 2011 10:53:18 +0100 Subject: [M3devel] m2tom3 In-Reply-To: <4EC694CC.1070004@lcwb.coop> References: <4EC2EB41.6010203@wickensonline.co.uk>, <4EC53FDD.2040301@lcwb.coop> <4EC694CC.1070004@lcwb.coop> Message-ID: <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> Hi Rodney, sorry for answering so late. Quoting "Rodney M. Bates" : > Olaf, is there a place in the elego-hosted repositories I can put this? > I don't find it already present in my local copy of cm3. > Can I create a new subdirectory, say in cm3/m3-tools? Of course, just cvs-add it. Please make sure that it compiles though. > On this topic, I have a few library packages that might be useful > to somebody someday. Would Elegosoft be interested in hosting them? As long as you don't upload gigabytes of M3 source code (let us know of that in advance :-), please feel free to add and share any library that you think may be useful for others. We should probably add some documentation for them and re-run and ship the m3tohtml results to the web server, but that can be done later. Thanks for your contributions, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Nov 23 16:18:34 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 23 Nov 2011 10:18:34 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> References: <4EC2EB41.6010203@wickensonline.co.uk> <4EC53FDD.2040301@lcwb.coop> <4EC694CC.1070004@lcwb.coop> <20111123105318.phcogkayu8gg4kw4@mail.elegosoft.com> Message-ID: <20111123151833.GA13397@topoi.pooq.com> On Wed, Nov 23, 2011 at 10:53:18AM +0100, Olaf Wagner wrote: > Hi Rodney, > > sorry for answering so late. > > Quoting "Rodney M. Bates" : > > >Olaf, is there a place in the elego-hosted repositories I can put this? > >I don't find it already present in my local copy of cm3. > >Can I create a new subdirectory, say in cm3/m3-tools? > > Of course, just cvs-add it. Please make sure that it compiles though. > > >On this topic, I have a few library packages that might be useful > >to somebody someday. Would Elegosoft be interested in hosting them? > > As long as you don't upload gigabytes of M3 source code (let us know > of that in advance :-), please feel free to add and share any library > that you think may be useful for others. > > We should probably add some documentation for them and re-run and > ship the m3tohtml results to the web server, but that can be done > later. > > Thanks for your contributions, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 Would it be useful to dual-licence new code under the LGPL(2 or later) on the remote chance that other parts of Modula 3 might someday also be so licenced. Or, for that matter, that someone might want to translate it to another language, by hand or otherwise? That would then be a derived work, also LGPL-able. Just trying to reduce future barriers to interoperation. -- hendrik > From dabenavidesd at yahoo.es Wed Nov 23 17:08:55 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 16:08:55 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111123151833.GA13397@topoi.pooq.com> Message-ID: <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> Hi all: if one were to rework MODULES INTERFACEs IMHO yes, would be useful, anyway, that should make no harm other's code (when appropitely veryfied at elast in ESC/Modula-3), when developing enough of libm3. A Short term could be m3core RT INTERFACES as they developed as a standard Modula-3, which they declare "free to use and implement". I however don't know about other's companies codes, since they could offer just that for their purposes, but that's less central of the issue. For instance linking other FOSS could be approved by that change in order to break down even further dependence. Inthe other side, DEC-SRC licence is pretty liberal, so it could be thought as GPL-compatible, which means that the same license is able to cope with the FOSS definitions, even that of FSF. Thanks in advance --- El mi?, 23/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 23 de noviembre, 2011 10:18 > On Wed, Nov 23, 2011 at 10:53:18AM > +0100, Olaf Wagner wrote: > > Hi Rodney, > > > > sorry for answering so late. > > > > Quoting "Rodney M. Bates" : > > > > >Olaf, is there a place in the elego-hosted > repositories I can put this? > > >I don't find it already present in my local copy > of cm3. > > >Can I create a new subdirectory, say in > cm3/m3-tools? > > > > Of course, just cvs-add it. Please make sure that it > compiles though. > > > > >On this topic, I have a few library packages that > might be useful > > >to somebody someday. Would Elegosoft be > interested in hosting them? > > > > As long as you don't upload gigabytes of M3 source > code (let us know > > of that in advance :-), please feel free to add and > share any library > > that you think may be useful for others. > > > > We should probably add some documentation for them and > re-run and > > ship the m3tohtml results to the web server, but that > can be done > > later. > > > > Thanks for your contributions, > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > Would it be useful to dual-licence new code under the > LGPL(2 or later) > on the remote chance that other parts of Modula 3 might > someday also be > so licenced. Or, for that matter, that someone might > want to translate > it to another language, by hand or otherwise? That > would then be a > derived work, also LGPL-able. > > Just trying to reduce future barriers to interoperation. > > -- hendrik > > > > From vintagecoder at aol.com Wed Nov 23 17:19:57 2011 From: vintagecoder at aol.com (vintagecoder at aol.com) Date: Wed, 23 Nov 2011 16:19:57 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <20111123151833.GA13397@topoi.pooq.com> Message-ID: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> > Would it be useful to dual-licence new code under the LGPL(2 or later) on > the remote chance that other parts of Modula 3 might someday also be so > licenced. Or, for that matter, that someone might want to translate it > to another language, by hand or otherwise? That would then be a derived > work, also LGPL-able. The Critical Mass license is perfectly fine. What is the sick fascination with GPL? Why can't people just leave things alone and not try to force other people to live according to their rules. LGPL is just a slippery slope. > Just trying to reduce future barriers to interoperation. Really? The GPL never reduced any barriers. It is *all about* barriers. You truly want to reduce future barriers? Then public-domain your code or use a BSD or MIT license. Or just use the Critical Mass license and stop trying to turn everything into Linux. From dabenavidesd at yahoo.es Wed Nov 23 17:51:13 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 16:51:13 +0000 (GMT) Subject: [M3devel] m2tom3 Message-ID: <1322067073.72825.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: In fact the bottom line is how we can create an environment enough capable of hosting several languages or at least enough easy to develop cross compilers from Pascal, Modula-2 and Simula like languages for the benefit of those interested in porting legacy applications in a Modern of the day SOTA programming system with high performance and still easy deployment, which is hard to find this days on other platforms even to older or new systems ranging from CDC and Algol systems to embedded platforms of the and a Code generation Interface for C-based languages, like Fail-Safe (IDL, see: http://www.yonezaki.cs.titech.ac.jp/Workshop/isss2003/slides/Suenaga.pdf ), or something like for SPIN's Cove, which is the best languages that could be safe enough to share RT structures with Modula-3, etc, else it has no point to re-implement those UNSAFE interfaces with C instead of Modula-3 code IMHO. Also as a way to allow further development in even that languages as well if so as needed. Thanks in advance --- El mi?, 23/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com, "Hendrik Boom" > Fecha: mi?rcoles, 23 de noviembre, 2011 11:08 > Hi all: > if one were to rework MODULES INTERFACEs IMHO yes, would be > useful, anyway, that should make no harm other's code (when > appropitely veryfied at elast in ESC/Modula-3), when > developing enough of libm3. A Short term could be > m3core RT INTERFACES as they developed as a standard > Modula-3, which they declare "free to use and implement". I > however don't know about other's companies codes, since they > could offer just that for their purposes, but that's less > central of the issue. For instance linking other FOSS could > be approved by that change in order to break down even > further dependence. > Inthe other side, DEC-SRC licence is pretty liberal, so it > could be thought as GPL-compatible, which means that > the same license is able to cope with the FOSS definitions, > even that of FSF. > Thanks in advance > > --- El mi?, 23/11/11, Hendrik Boom > escribi?: > > > De: Hendrik Boom > > Asunto: Re: [M3devel] m2tom3 > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 23 de noviembre, 2011 10:18 > > On Wed, Nov 23, 2011 at 10:53:18AM > > +0100, Olaf Wagner wrote: > > > Hi Rodney, > > > > > > sorry for answering so late. > > > > > > Quoting "Rodney M. Bates" : > > > > > > >Olaf, is there a place in the elego-hosted > > repositories I can put this? > > > >I don't find it already present in my local > copy > > of cm3. > > > >Can I create a new subdirectory, say in > > cm3/m3-tools? > > > > > > Of course, just cvs-add it. Please make sure that > it > > compiles though. > > > > > > >On this topic, I have a few library packages > that > > might be useful > > > >to somebody someday. Would Elegosoft > be > > interested in hosting them? > > > > > > As long as you don't upload gigabytes of M3 > source > > code (let us know > > > of that in advance :-), please feel free to add > and > > share any library > > > that you think may be useful for others. > > > > > > We should probably add some documentation for > them and > > re-run and > > > ship the m3tohtml results to the web server, but > that > > can be done > > > later. > > > > > > Thanks for your contributions, > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 > 2345 > > 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > > USt-IdNr: DE163214194 > > > > Would it be useful to dual-licence new code under the > > LGPL(2 or later) > > on the remote chance that other parts of Modula 3 > might > > someday also be > > so licenced. Or, for that matter, that someone > might > > want to translate > > it to another language, by hand or otherwise? > That > > would then be a > > derived work, also LGPL-able. > > > > Just trying to reduce future barriers to > interoperation. > > > > -- hendrik > > > > > > > > From dabenavidesd at yahoo.es Wed Nov 23 18:16:50 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 23 Nov 2011 17:16:50 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> Message-ID: <1322068610.69293.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: a perfect example of compatibility is the DEC-SRC SRCCollector Interface inter with GNU C Boehm's Collector compatible interface: http://opensource.apple.com/source/gcc/gcc-5493/boehm-gc/doc/README.macros And that happened a long time before [1] DEC-SRC closing so they knew at least that it could be possible to compile (and inferring types)/link to interchange both collectors (fully capable and enough compatible interfaces to make GC-safe in both DEC-SRC Modula-3 and GNU C languages, where is the counterexample for what you say) flawlessly say in any environment. Thanks in advance [1] H.-J. Boehm and Z. Shao, ?Inferring Type Maps during Garbage Collection,? IN OOPSLA ?93 WORKSHOP ON MEMORY MANAGEMENT AND GARBAGE COLLECTION, 1993. --- El mi?, 23/11/11, vintagecoder at aol.com escribi?: > De: vintagecoder at aol.com > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 23 de noviembre, 2011 11:19 > > Would it be useful to > dual-licence new code under the LGPL(2 or later) on > > the remote chance that other parts of Modula 3 might > someday also be so > > licenced. Or, for that matter, that someone > might want to translate it > > to another language, by hand or otherwise? That > would then be a derived > > work, also LGPL-able. > > The Critical Mass license is perfectly fine. What is the > sick fascination > with GPL? Why can't people just leave things alone and not > try to force > other people to live according to their rules. LGPL is just > a slippery > slope. > > > Just trying to reduce future barriers to > interoperation. > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > You truly want to reduce future barriers? Then > public-domain your code or > use a BSD or MIT license. Or just use the Critical Mass > license and stop > trying to turn everything into Linux. > From dabenavidesd at yahoo.es Thu Nov 24 22:30:35 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 24 Nov 2011 21:30:35 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <1322068610.69293.YahooMailClassic@web29704.mail.ird.yahoo.com> Message-ID: <1322170235.80764.YahooMailClassic@web29707.mail.ird.yahoo.com> Hi all: in fact we need to address surely in a near future since xds Development Environment system has DEC-SRC Modula-3 infrastructure for Modula-2, Oberon-2 mixable Modules project compatibility: http://www.excelsior-usa.com/xds.html This could of big help for a lot of good tools that have applied for Modula-3 type system R&D. So instead of thinking in license mess, we would be thinking in language mixing. About that they are thinking in releasing the source codes, perhaps, if Elego folks would show interest we could bring some of their tools. The bottom line of this is we would have same capabilities like CM3-IDE ability to navigate sources, so to have source to source transformations seemingly navigation and code generations capabilities (like for C in XDS system). I suggest we can make something for that, given the same structure of compilers, of course there is a lot of work, but we could do it, you are so great programmers. Thanks in advance --- El mi?, 23/11/11, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com, vintagecoder at aol.com > Fecha: mi?rcoles, 23 de noviembre, 2011 12:16 > Hi all: > a perfect example of compatibility is the DEC-SRC > SRCCollector Interface inter with GNU C Boehm's Collector > compatible interface: > http://opensource.apple.com/source/gcc/gcc-5493/boehm-gc/doc/README.macros > > And that happened a long time before [1] DEC-SRC closing so > they knew at least that it could be possible to compile (and > inferring types)/link to interchange both collectors (fully > capable and enough compatible interfaces to make GC-safe in > both DEC-SRC Modula-3 and GNU C languages, where is the > counterexample for what you say) flawlessly say in any > environment. > > Thanks in advance > > [1] H.-J. Boehm and Z. Shao, ?Inferring Type Maps during > Garbage Collection,? IN OOPSLA ?93 WORKSHOP ON MEMORY > MANAGEMENT AND GARBAGE COLLECTION, 1993. > > > --- El mi?, 23/11/11, vintagecoder at aol.com > > escribi?: > > > De: vintagecoder at aol.com > > > Asunto: Re: [M3devel] m2tom3 > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 23 de noviembre, 2011 11:19 > > > Would it be useful to > > dual-licence new code under the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might > > someday also be so > > > licenced. Or, for that matter, that > someone > > might want to translate it > > > to another language, by hand or otherwise? > That > > would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the > > sick fascination > > with GPL? Why can't people just leave things alone and > not > > try to force > > other people to live according to their rules. LGPL is > just > > a slippery > > slope. > > > > > Just trying to reduce future barriers to > > interoperation. > > > > Really? The GPL never reduced any barriers. It is > *all > > about* barriers. > > > > You truly want to reduce future barriers? Then > > public-domain your code or > > use a BSD or MIT license. Or just use the Critical > Mass > > license and stop > > trying to turn everything into Linux. > > > From hendrik at topoi.pooq.com Thu Nov 24 23:13:43 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 24 Nov 2011 17:13:43 -0500 Subject: [M3devel] licences, again In-Reply-To: <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> References: <20111123151833.GA13397@topoi.pooq.com> <1322064535.10522.YahooMailClassic@web29711.mail.ird.yahoo.com> Message-ID: <20111124221343.GA13709@topoi.pooq.com> On Wed, Nov 23, 2011 at 04:08:55PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > if one were to rework MODULES INTERFACEs IMHO yes, would be useful, anyway, that should make no harm other's code (when appropitely veryfied at elast in ESC/Modula-3), when developing enough of libm3. A Short term could be m3core RT INTERFACES as they developed as a standard Modula-3, which they declare "free to use and implement". I however don't know about other's companies codes, since they could offer just that for their purposes, but that's less central of the issue. For instance linking other FOSS could be approved by that change in order to break down even further dependence. I can't say I really understand this paragraph. > Inthe other side, DEC-SRC licence is pretty liberal, so it could be thought as GPL-compatible, which means that the same license is able to cope with the FOSS definitions, even that of FSF. Certainly, I'd like it to be compatible with GPL. But I've been told that the FSF considers the DEC-SRC licence incompatible with the GPL. -- hendrik From hendrik at topoi.pooq.com Thu Nov 24 23:24:20 2011 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 24 Nov 2011 17:24:20 -0500 Subject: [M3devel] m2tom3 In-Reply-To: <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> References: <20111123151833.GA13397@topoi.pooq.com> <201111231620.pANGI0cI020515@ims-d11.mx.aol.com> Message-ID: <20111124222420.GB13709@topoi.pooq.com> On Wed, Nov 23, 2011 at 04:19:57PM +0000, vintagecoder at aol.com wrote: > > Would it be useful to dual-licence new code under the LGPL(2 or later) on > > the remote chance that other parts of Modula 3 might someday also be so > > licenced. Or, for that matter, that someone might want to translate it > > to another language, by hand or otherwise? That would then be a derived > > work, also LGPL-able. > > The Critical Mass license is perfectly fine. What is the sick fascination > with GPL? Just that a lot of free software *is* released inder the GPL, and it would be convenient to be compatible. > Why can't people just leave things alone and not try to force > other people to live according to their rules. LGPL is just a slippery > slope. > > > Just trying to reduce future barriers to interoperation. > > Really? The GPL never reduced any barriers. It is *all about* barriers. It's about limiting one's freedom to limit others' freedom. And that is a barrrier, right. But the way to bypass the barrier is to release code under multiple licences, the GPL or LGPL together with whatever licence you prefer. Potential users can then choose whichever licence suits them. > > You truly want to reduce future barriers? Then public-domain your code or > use a BSD or MIT license. Those licences would do, yes. I suspect they're compatible with both the SRC licence (which the CM licence is based on) and GPL (but can anyone confirm that?). > Or just use the Critical Mass license and stop > trying to turn everything into Linux. It's actually on Windows that it's a particular problem. It's usual to distribute binaries there. Most potential Windows users don't have their own software development tools and can only use prelinked binaries. It's on Posix systems such as Linux that we have less of a problem, because they usually come with adequate development tools. -- hendrik From dabenavidesd at yahoo.es Fri Nov 25 00:46:32 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 24 Nov 2011 23:46:32 +0000 (GMT) Subject: [M3devel] licences, again In-Reply-To: <20111124221343.GA13709@topoi.pooq.com> Message-ID: <1322178392.49293.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi: thanks for the message. Again I meant, that surely we could work out this by recording all libm3 libraries suddenly and then make the all library LGPL (as suggested by Richard Stallman) or whatever the Folks want. So, I guess the best approach is given that the DEC-SRC report declares Modula-3 free use and implement as stated there: ftp://ftp.hpl.hp.com/pub/dec/SRC/research-reports/SRC-052.pdf "The right to implement or use the Modula-3 language is unrestricted" Therefore as some libm3 INTERFACEs are part of that Language Definition as some in m3core (which should be all in m3core or in libm3 but not in both IMHO) we could code MODULEs an license them in again whatever folks want (or even on several license but carefully, as DEC-SRC did: ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/copyright.html ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/commercial.html ftp://ftp.hpl.hp.com/pub/dec/SRC/hypertext/Modula-3/non_commercial.html But I think they are all exactly the same document, so clearly there is was ? outdated and error-prone documentation (the tittle is wrong anyway in the commercial.html file), BTW Elego has a broken link: http://modula3.elegosoft.com/cm3/doc/reference/license.html in http://modula3.elegosoft.com/rsrc/digital-license.html Finally the history tells they "recreated" the Commercial license, I guess this was related to the fact that Pine Creek Software left Modula-3 Business somewhere in the 1993 or so as I recall. So that could be the effect of that. Anyway the new license docs seem like '94 so would be good to see what is the status of the current license, and that's the reason RMS said this was not good for FSF, since I think they were talking about this before '94 Naturally someone should be able to tell what the heck is this all about, first non-commercial license, the first commercial one and the newest. There is a tool the did in DEC-SRC, we could have to look for that: http://www.lim.nl/monitor/hector.html p 22 see: http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-92.pdf Thanks in advance --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] licences, again > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:13 > On Wed, Nov 23, 2011 at 04:08:55PM > +0000, Daniel Alejandro Benavides D. wrote: > > Hi all: > > if one were to rework MODULES INTERFACEs IMHO yes, > would be useful, anyway, that should make no harm other's > code (when appropitely veryfied at elast in ESC/Modula-3), > when developing enough of libm3. A Short term could be > m3core RT INTERFACES as they developed as a standard > Modula-3, which they declare "free to use and implement". I > however don't know about other's companies codes, since they > could offer just that for their purposes, but that's less > central of the issue. For instance linking other FOSS could > be approved by that change in order to break down even > further dependence. > > I can't say I really understand this paragraph. > > > Inthe other side, DEC-SRC licence is pretty liberal, > so it could be thought as GPL-compatible, which means > that the same license is able to cope with the FOSS > definitions, even that of FSF. > > Certainly, I'd like it to be compatible with GPL. > > But I've been told that the FSF considers the DEC-SRC > licence > incompatible with the GPL. > > -- hendrik > From dabenavidesd at yahoo.es Fri Nov 25 01:41:33 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 25 Nov 2011 00:41:33 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <1322181693.78177.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi all: I knew that for instance OpenWatcom or Watcom by that time had written a piece of code with resemblance of Modula-3 I guess NT implementation so I guess as I recall I saw the DEC-SRC Copyright license for commercial product there but I can't get into it, I would need time to dig their sources if there is any still that has that license, see: http://en.wikipedia.org/wiki/Open_Watcom See dates match exactly before 1994 license change http://research.microsoft.com/pubs/64242/implementingcvs.pdf There is controversy with Debian and Fedora legal teams, which I don't care more than OpenWatcom compiler had Modula-3 based code in their time, so if they got that before 94 (in 93) I guess this is the the way to go to understand the legalese, or say that DEC granted its license in other licenses which is sort of the idea in the GPL case even if it is not adjusted to it. IF FSF wants to ask for their license I don't see any reason for preventing asking that for. Thanks in advance --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:24 > On Wed, Nov 23, 2011 at 04:19:57PM > +0000, vintagecoder at aol.com > wrote: > > > Would it be useful to dual-licence new code under > the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might someday also be so > > > licenced. Or, for that matter, that someone > might want to translate it > > > to another language, by hand or otherwise? > That would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the sick fascination > > with GPL? > > Just that a lot of free software *is* released inder the > GPL, and it > would be convenient to be compatible. > > > Why can't people just leave things alone and not try > to force > > other people to live according to their rules. LGPL is > just a slippery > > slope. > > > > > Just trying to reduce future barriers to > interoperation. > > > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > It's about limiting one's freedom to limit others' > freedom. And that > is a barrrier, right. But the way to bypass the > barrier is to release > code under multiple licences, the GPL or LGPL together with > whatever > licence you prefer. Potential users can then choose > whichever licence > suits them. > > > > You truly want to reduce future barriers? Then > public-domain your code or > > use a BSD or MIT license. > > Those licences would do, yes. I suspect they're > compatible with both > the SRC licence (which the CM licence is based on) and GPL > (but can > anyone confirm that?). > > > Or just use the Critical Mass license and stop > > trying to turn everything into Linux. > > It's actually on Windows that it's a particular > problem. It's usual to > distribute binaries there. Most potential Windows > users don't have > their own software development tools and can only use > prelinked > binaries. > > It's on Posix systems such as Linux that we have less of a > problem, > because they usually come with adequate development tools. > > -- hendrik > > From dabenavidesd at yahoo.es Fri Nov 25 04:28:22 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 25 Nov 2011 03:28:22 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <1322191702.57301.YahooMailClassic@web29715.mail.ird.yahoo.com> Hi all: in fact i think MS has the anti-free software parade creating cells of users in Universities, because they see how dramatically Java ad many others like GNU and Linux and all projects are just sweeping them (sorry if the words sound strong but what it feels is like that) as much they sweep in the industry, well most of times, say 90%. That's why they tell the history of their concern of Copyrights, which somehow is a FSF concern too if that was the case with the Modula-3 gnu based tools I see (here MS uses the naive terms Author's rights), so the idea behind this is they feel "bad" if the copy proprietary software is shared and so the rest is history, bu the main threat could not been even that but the actual fact that in the "Cloud", or virtual networked environments we will need to find a way of obviating or bypass this regulations, since is useless there, sicne it will be bypassed anyway, even if you go today to a video site store you get music that would be paid for in some parts of the world but still free in others which is point-less anyway if so, but that depends in where you are going to access those things but if everything is virtual it senseless, since would one make virtual systsems in a X country prohibit if they serve in Y country, obiously not I guess! I remember in fact a tale about virtual system trying to control that you can't give a web page to another individual, which sorts of feels bad, you know, you can't show anybody a thing is you pay for (If I can find the reference I will share it). The antithesis was developed long before an Image-based Electronic Library [1], in AT&T Labs, where they associated for Copyright compliance efforts with Copyright Clearance Center CCC to ask the authors that didn't agree to allow photocopying their paper texts, to ask them directly if they might do so for their project. I imagine a similar thing for the new tools on the Virtual Networked environments, where you share code directly on the net and so get involved in those efforts is something that is making proprietary users to feel threatened by that if so, for instance we could really make a Copyright clearance of Modula-3 sources (but implicitly telling FSF that we can share with them if they want to share code with us as well, which they could need who knows as I believe there are network packages here and there for Linux, etc. in Modula-3) so FSF feels happier and might want to ask the sources in other licenses which I believe is what concerns them they would do easier. That's my little idea of the new computation era "issues". Thanks in advance. [1] G. A. Story, L. O?Gorman, D. Fox, L. L. Schaper, and H. V. Jagadish, ?The RightPages image-based electronic library for alerting and browsing,? Computer, vol. 25, pp. 17-26, Sep. 1992. --- El jue, 24/11/11, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: jueves, 24 de noviembre, 2011 17:24 > On Wed, Nov 23, 2011 at 04:19:57PM > +0000, vintagecoder at aol.com > wrote: > > > Would it be useful to dual-licence new code under > the LGPL(2 or later) on > > > the remote chance that other parts of Modula 3 > might someday also be so > > > licenced. Or, for that matter, that someone > might want to translate it > > > to another language, by hand or otherwise? > That would then be a derived > > > work, also LGPL-able. > > > > The Critical Mass license is perfectly fine. What is > the sick fascination > > with GPL? > > Just that a lot of free software *is* released inder the > GPL, and it > would be convenient to be compatible. > > > Why can't people just leave things alone and not try > to force > > other people to live according to their rules. LGPL is > just a slippery > > slope. > > > > > Just trying to reduce future barriers to > interoperation. > > > > Really? The GPL never reduced any barriers. It is *all > about* barriers. > > It's about limiting one's freedom to limit others' > freedom. And that > is a barrrier, right. But the way to bypass the > barrier is to release > code under multiple licences, the GPL or LGPL together with > whatever > licence you prefer. Potential users can then choose > whichever licence > suits them. > > > > You truly want to reduce future barriers? Then > public-domain your code or > > use a BSD or MIT license. > > Those licences would do, yes. I suspect they're > compatible with both > the SRC licence (which the CM licence is based on) and GPL > (but can > anyone confirm that?). > > > Or just use the Critical Mass license and stop > > trying to turn everything into Linux. > > It's actually on Windows that it's a particular > problem. It's usual to > distribute binaries there. Most potential Windows > users don't have > their own software development tools and can only use > prelinked > binaries. > > It's on Posix systems such as Linux that we have less of a > problem, > because they usually come with adequate development tools. > > -- hendrik > > From vintagecoder at aol.com Sat Nov 26 19:35:45 2011 From: vintagecoder at aol.com (vintagecoder at aol.com) Date: Sat, 26 Nov 2011 18:35:45 +0000 Subject: [M3devel] m2tom3 In-Reply-To: <20111124222420.GB13709@topoi.pooq.com> Message-ID: <201111261835.pAQIZofL030035@ims-m12.mx.aol.com> >> The Critical Mass license is perfectly fine. What is the sick fascination >> with GPL? >Just that a lot of free software *is* released inder the GPL, and it >would be convenient to be compatible. A lot of /Linux/ software has been infected by GPL's viral forcible open source license. BSD and MIT licenses existed before GPL, they are truly /free/ and open source licenses, and they are also compatible with the GPL (for me that compatibility is worth nothing). If you use the GPL you will contaminate the original DEC license and people who would have contributed or included your software in situations where BSD and MIT licenses are common and accepted but who don't like GPL (OpenBSD for a notable example) will have problems with it. I personally have a problem with it. I was very pleased to find CM3 and the SRC license and I would be very dissapointed if it was contaminated by the GPL in the future. If you are going for freedom, there are a few good choices and none of them are GPL. I cannot any reason other than politics for adding the GPL to a preexisting product. I sincerely hope elegosoft avoids this! >> Why can't people just leave things alone and not try to force >> other people to live according to their rules. LGPL is just a slippery >> slope. > > Just trying to reduce future barriers to interoperation. > >> Really? The GPL never reduced any barriers. It is *all about* barriers. > It's about limiting one's freedom to limit others' freedom. And that is > a barrrier, right. But the way to bypass the barrier is to release code > under multiple licences, the GPL or LGPL together with whatever licence > you prefer. Potential users can then choose whichever licence suits > them. Mixing and matching licenses doesn't help because the GPL adds restrictions that aren't present in true free open source licenses. If you feel it necessary to license, what is the reason? Do you want to maintain ownership and foster community participation? Then use BSD or MIT licenses which are compatible with any open source license. Do you want to make a political statement and jump on a bandwagon over a cliff to the point where many big operations won't touch your product for fear of having to expose their code? Choose GPL. The GPL is incompatible with most open source licenses because it is not free, it adds restrictions that other licenses don't have. I read recently MINIX had said they are attempting to build commercial support and demand for their OS and they found the BSD license a significant help in doing that. They said many potential customers object to the GPL. From a standpoint of true freedom /and/ possible commercial success the BSD and MIT style licenses seem so obviously superior to a viral forcible open source license, I just can't see why anybody would choose the GPL except for purely political reasons. It's self destructive. >> You truly want to reduce future barriers? Then public-domain your code or >> use a BSD or MIT license. >Those licences would do, yes. I suspect they're compatible with both >the SRC licence (which the CM licence is based on) and GPL (but can >anyone confirm that?). Yes, I can confirm they're compatible from GPL's standpoint. I don't know about the DEC/SRC license. >> Or just use the Critical Mass license and stop >> trying to turn everything into Linux. > It's actually on Windows that it's a particular problem. It's usual to > distribute binaries there. Most potential Windows users don't have their > own software development tools and can only use prelinked binaries. I understand Windows users are mostly stuck with prebuilt applications. I don't understand what licensing considerations have to do with that. If you use the SRC license does that have any effect on the executables? If so, how will adding code with other licenses whether BSD, MIT, or even GPL make anything simpler or change anything? If the CM3 runtime is included in the SRC license then that is the low bar, that is, you will only be able to add restrictions to it, not remove any. If the runtime is not included then I think it would be extremely unwise to encumber it any further. I feel it would be unwise to encumber it any further in any case. From dabenavidesd at yahoo.es Sat Nov 26 20:42:30 2011 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 26 Nov 2011 19:42:30 +0000 (GMT) Subject: [M3devel] m2tom3 In-Reply-To: <201111261835.pAQIZofL030035@ims-m12.mx.aol.com> Message-ID: <1322336550.58691.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: If anyone working a networking tool uses a _DEC_ license why would you suggest asking they to release it in a different license if only that makes work with another package to _DEC_. Is their obligation to release that, according to the original license you can not ask them to release their sources in that other license so, unless you clear the _DEC_ license then it makes no sense to do that later, in that view it's necessary to ask them more than one time. So that makes the all idea of sub license not clever at all which is what others did. The point is whatever package uses Modula-3 will need that license. Does this feel fair? I say if you have another license (and commercial house like Pine Creek Software, or others as well), makes sense since you can actually give away your software or not (I say this because once we have the sources on a "cloud" term BTW rejected by myself and for once and all by RMS), will be given to anyone in a public "virtual network", so you can not ask them to release their packages in that other license if it is derivative or not see PM3. That's why I guess _DEC_ released it in the '94 as a pretty liberal to have just one. So we can have the idea of a "public cloud" and a private one in one and feel free to ask them to do so, anyway the DEC license doesn't prohibit linking against Modula-3 GPL libraries, or why is that lm is linked in Modula-3. You need to look at the facts and see that it can be licensed like that since it's your will to do so, but do your code need that is useless once again because it will bypassed anyway (is against that freedom you want). The world is not just one point, even in the "virtual networks", and everyone should be free to pass around software, that's the main "resource" of a society as RMS stays, is what creates a good society in which we can live in, even if you don't agree the arguments is clever enough to give it a try for such a society in digital terms this is free software and society around it that makes it if so. If none want that then it is pointless to ask the _DEC_ license to be free for RMS etc want that ever, as he did but was rejected by '88 to Olivetti, it is us who want that, theirs is their business to accept it or not (asking to give them the copyrights seems like they can change their license to whatever they like and I can't agree with that as well, as _DEC_ I think didn't agree to do in their time their efforts to do so). Indeed _DEC_ tried with '94 license, whatever it feels right now for FSF I don't know but I like more the idea of having 2 licenses, since it's us who want that change, but again, giving it two or three or more licenses makes no much sense for my point of view if anyone wants that, it is useless, that's the point of the unique '94 license, much more liberty that anyone can have (RMS before '94 denial is a show of that as well, I agree with you on that). Thanks in advance --- El s?b, 26/11/11, vintagecoder at aol.com escribi?: > De: vintagecoder at aol.com > Asunto: Re: [M3devel] m2tom3 > Para: m3devel at elegosoft.com > Fecha: s?bado, 26 de noviembre, 2011 13:35 > >> The Critical Mass license is > perfectly fine. What is the sick fascination > >> with GPL? > > >Just that a lot of free software *is* released inder > the GPL, and it > >would be convenient to be compatible. > > A lot of /Linux/ software has been infected by GPL's viral > forcible open > source license. BSD and MIT licenses existed before GPL, > they are truly > /free/ and open source licenses, and they are also > compatible with the GPL > (for me that compatibility is worth nothing). > > If you use the GPL you will contaminate the original DEC > license and > people who would have contributed or included your software > in situations > where BSD and MIT licenses are common and accepted but who > don't like GPL > (OpenBSD for a notable example) will have problems with it. > I personally > have a problem with it. I was very pleased to find CM3 and > the SRC license > and I would be very dissapointed if it was contaminated by > the GPL in the > future. > > If you are going for freedom, there are a few good choices > and none of them > are GPL. I cannot any reason other than politics for adding > the GPL to a > preexisting product. I sincerely hope elegosoft avoids > this! > > >> Why can't people just leave things alone and not > try to force > >> other people to live according to their rules. > LGPL is just a slippery > >> slope. > > > > Just trying to reduce future barriers to > interoperation. > > > >> Really? The GPL never reduced any barriers. It is > *all about* barriers. > > > It's about limiting one's freedom to limit others' > freedom. And that is > > a barrrier, right. But the way to bypass the > barrier is to release code > > under multiple licences, the GPL or LGPL together with > whatever licence > > you prefer. Potential users can then choose > whichever licence suits > > them. > > Mixing and matching licenses doesn't help because the GPL > adds restrictions > that aren't present in true free open source licenses. If > you feel it > necessary to license, what is the reason? Do you want to > maintain ownership > and foster community participation? Then use BSD or MIT > licenses which are > compatible with any open source license. Do you want to > make a political > statement and jump on a bandwagon over a cliff to the point > where many big > operations won't touch your product for fear of having to > expose their > code? Choose GPL. The GPL is incompatible with most open > source licenses > because it is not free, it adds restrictions that other > licenses don't have. > > I read recently MINIX had said they are attempting to build > commercial > support and demand for their OS and they found the BSD > license a > significant help in doing that. They said many potential > customers object > to the GPL. > > From a standpoint of true freedom /and/ possible commercial > success the BSD > and MIT style licenses seem so obviously superior to a > viral forcible open > source license, I just can't see why anybody would choose > the GPL except > for purely political reasons. It's self destructive. > > >> You truly want to reduce future barriers? Then > public-domain your code or > >> use a BSD or MIT license. > > >Those licences would do, yes. I suspect they're > compatible with both > >the SRC licence (which the CM licence is based on) and > GPL (but can > >anyone confirm that?). > > Yes, I can confirm they're compatible from GPL's > standpoint. I don't know > about the DEC/SRC license. > > >> Or just use the Critical Mass license and stop > >> trying to turn everything into Linux. > > > It's actually on Windows that it's a particular > problem. It's usual to > > distribute binaries there. Most potential > Windows users don't have their > > own software development tools and can only use > prelinked binaries. > > I understand Windows users are mostly stuck with prebuilt > applications. I > don't understand what licensing considerations have to do > with that. If you > use the SRC license does that have any effect on the > executables? If so, > how will adding code with other licenses whether BSD, MIT, > or even GPL make > anything simpler or change anything? If the CM3 runtime is > included in the > SRC license then that is the low bar, that is, you will > only be able to add > restrictions to it, not remove any. If the runtime is not > included then I > think it would be extremely unwise to encumber it any > further. I feel it > would be unwise to encumber it any further in any case. > > > >