[M3devel] About Juno-2 and automating debugging software

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Mon Jan 31 05:20:58 CET 2011

Hi all:
yes, I believe is doable especially if you think this issue comes again in another form, the AI guys thinking what went wrong, well nothing went wrong as I realize now, there is a lot of research certainly, but in the end is just the same thing like before, and you can see this like the reuse of concepts of prior knowledge as is mentioned between other by Dr Andrew Tanenbaum, it just happens when something like this: see, the GPGPU GPU stuff alike is a nother come of the concept of explicit parallelism and its implication in computing fields, surely more developed in terms of the hardware this was I believe, but at the end is just another way of calling Transputers in earlier times, is just like it, then it was not an abandoned thing like before, just a reuse of the concept, and in practical terms this what it is the Occam Occam2 and alike languages; there is one in particular of my interest here the one built for drawing using CSP of Hoare, the language
 is called Armadillo see a slide show here, specially check for the Computer magazine backcover in p. 6 in:
(Also its Armadillo, small, but kind of sweet animal and very nicely armored, it is found here in the wildness parts here in the sea costs of the Atlantic Caribbean sea in the north of south America, but also a kind domestic animal if you live in some country like this here too) I believe I have no seen this animal in any Oreilly front cover book, I believe from the ones I have seen (am I correct?).
Well to state this less profound, the called abstraction for machine generation of this sort of derivate of Lisp Logo CSP and Modula-3 uses the Modula-3 structural equivalence type system part of Modula-3 type checking and the most part of it dynamically typecheking of it, so its Object Oriented if you can say that. Still it has records as in Modula-3 and fell like you were there, never the less, all sort of non-imperative forms of the language, like floating point types and sort of Arithmetic ones, well sort of the integer I believe, though It might be expandable if one just arranges that as well I believe in its core runtime.
It's not supposed to be interactively run but to be to run semi-interpretable as an Armacode binary representation up to a tree which takes not so much time to build up and run to the execution time, also it has an option to be dynamically interpreted as a core of a JIT inserted calls to runtime functions I think. It serves well for the purpose of checking it with a possible ESC/Armadillo checker but also permits same kind of applicable and beyond Modula-3 optimizations also via an hypothetical super optimizer code generator for Modula-3 language as linker and loader module subsystem.
Instead of having if its own interpretation subsystem by itself, it lives and relies on the connection with other parts of the system like m3-ui and function from Modula-3 IO to rightly process nice and fast graphics by its own self extension libraries and data types, like turtle, etc.
Well, I just thought this might be helpful to find a better way to analyze a possible upgraded middle end interface for future CUDA or OpenCL platforms in the way it works for Modula-3 threads and types, with such an abstraction which perhaps does allow to create an accurate creative Juno-2 optimizations and stuff from there too that might be useful to speed up it too.
It might be useful to note the product mentioned in the slide in the terms it writes as a Multi-transputer, sort of a multi-user high middle-end server which came with open OS soured and customizable processor interconnection and compatibility to other operating systems via LAN NICs.
Sort even nicer profilability than one may think, very advanced for this days I still would say, or at least sophisticated for its time (compared to this times), see an explanation of its architecture:
In any sense it is not intended to create a bigger scene just short pictures the bigger problem to dedicate more time to less independent functionality like interoperability between both platforms and stuff alike.
Well, hope it's bit of contribution makes a good chance to create workable for real platform for the intent to continue this eventually, some of its last effort was I see:
which sort of an amenable way of coping with its development research, see for the Transterpreter part or Multi-Transterpreter :)  
Thanks in advance   

--- El dom, 30/1/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribió:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] About Juno-2 and automating debugging software
> Para: m3devel at elegosoft.com
> Fecha: domingo, 30 de enero, 2011 00:43
> Hi all:
> I think the speed improvement we might have in Juno-2 (to
> prove the concept) is to develop an interface for the
> constraint equational non-linear solving, perhaps done in
> CUDA see:
> http://en.wikipedia.org/wiki/CUDA
> like interface or OpenCL if so, and perhaps create a model
> for it under SOFA, see:
> http://en.wikipedia.org/wiki/SOFA_(Simulation_Open_Framework_Architecture)
> like model as some solvers already do that:
> http://www.sofa-framework.org/docs/sofa-tled-isbms08.pdf
> Also a FPU model would be needed of it or added to current
> modes of operation of Float point types, besides tohers like
> legacy x87 support, and newer ones.
> In this way we could prove the interface and give a proof
> of the concept.
> Indeed is heavy work and might not be reasonable to put
> first in a TODO list, but be aware this guys of GPGPU are
> creating so many things like large array of clusters to
> processing any kind of data, we might try to do that or some
> of it. And you know time is running for all and every should
> be keeping the pace.
> Perhaps this would require some sophistication in the
> needed machinery like 2 or three GPGPU or so, but still
> worth the value I think
> Thanks in advance,
> PD please if anybody has a CUDA or OpenCL interface design
> or already in mind or any ideas on this please speak up 
> --- El sáb, 29/1/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> escribió:
> > De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> > Asunto: [M3devel] About Juno-2 and automating
> debugging software
> > Para: m3devel at elegosoft.com
> > Fecha: sábado, 29 de enero, 2011 21:18
> > Hi all:
> > I was watching a book, sort of wondering what your
> ideas
> > you might have about that.
> > The idea behind this book, is sort of the same in
> some
> > point to what it is ESC/Modula-3.
> > in
> > [1] W. R. Murray, Automatic program debugging for
> > intelligent tutoring systems. Pitman, 1988.
> > A technical report here, get it:
> > ftp://ftp.cs.utexas.edu/pub/AI-Lab/tech-reports/UT-AI-TR-86-27.pdf
> > 
> > You will see its rationale is that a program must be
> > capable of catching more bugs and errors from the
> program,
> > than a syntactical analyzer, which is the idea behind
> > ESC/Modula-3, even if not a fully decidable problem as
> Greg
> > Neslon says.
> > 
> > Well I just put it there so we may see how about such
> a
> > thing an Automatic debugger in Juno-2, as the
> Automatic
> > Program Debugger is a declarative language Lisp subset
> and a
> > subset of Lisp implementation is available, sort of
> nice
> > thing to have already and Boyer-Moore underneath it
> theorem
> > prover also available, see on:
> > http://www.cs.utexas.edu/~moore/best-ideas/nqthm/index.html
> > (Unreacheable code, etc like program errors, etc).
> > 
> > Sort of nice having strong competence in the arena
> (see
> > on:
> > http://www.cs.cmu.edu/afs/cs/project/jair/pub/volume4/bhansali96a-html/paper.htm
> >  ) with sketchup and stuff, and Juno-2
> alternative JVM
> > already written backend and so (not for animations but
> sort
> > amenable for dynamic code generation?).
> > Only missing thing was just Prolog logical compiler
> but
> > also being written one for proof of soundness of
> modula-3
> > type system typechecking 
> > Thanks in advance
> > 
> > 
> > 
> > 


More information about the M3devel mailing list