[M3devel] wrapping postgresql library not enough

Thu Apr 21 18:27:45 CEST 2011

Hi all:
sure I can actually it work ¡s with WeakRef, somehow interesting, is there a m3-db/m3postgresql or ?
Besides the compilation problems, zeus3D package misses sources of at least 4 interface files and its not public dependences:
http://www.cs.arizona.edu/~collberg/Research/Modula-3/m3sources/html/zeus3D/src/

Aux, Camera, G, Light perhaps they were exported as hide_Interface() with its own modules if so. They are a kind of helper or friend modules ti it, so they are missing in public three there.
There is also a local copy of Obliq and Modula-3 packages of modules of models of lego tools, so it might be interesting for somebody to play with them, it's fairly a good size library written by an old M3 friend :), as are the algorithm animations done for zeus3D at DEC SRC. There is another one built package to animate distributed protocols called Zada, it might be interesting  to plug it all, even there is a formal specification of the same problem, a Manufacturing Cell, local projects name was Didactic Manufacturing Cell thesis (all sources available for free just that Obliq is not working as far I can tell)
Zada related relevant links (missing main web page is not under development any more, maybe we should ask them what they have about it and perhaps even their thesis) they had even audio:
http://ls4-www.cs.tu-dortmund.de/RVS/V-DA/daa-agarwal.html

http://ls4-www.cs.tu-dortmund.de/RVS/Exports/EB_PG225.ps.Z

http://ls4-www.cs.tu-dortmund.de/RVS/V-DA/daa-kukasch.html

So its would a good package animation example of lego tools, specifications, and protocols of all the framework, don't you think? 

Thanks in advance

PD: just if you care of and have at 2 PM ET today there is a conference on embedded software verification, so it might be good to see what this guys are looking for, maybe we can give them a look of it?
http://www.eetimes.com/design/eda-design/4215099/Using-verification-coverage-with-formal-analysis

--- El jue, 21/4/11, Mika Nystrom <mika at async.caltech.edu> escribió:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] wrapping postgresql library not enough
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> Fecha: jueves, 21 de abril, 2011 10:10
> Hi Daniel,
> 
> Sure I'd be happy to look at it (although I *may* already
> have fixed my
> problems, I don't know).  Would it be OK to add the
> PSQL driver you are talking
> about to CM3?
> 
> Can you give me a filename of some file you think would be
> in zeus3d and I can
> go looking in all my files for it?
> 
>      Mika
> 
> "Daniel Alejandro Benavides D." writes:
> >Hi Mika:
> >I have a local copy of Daniel Solaz's 2001 PSQL driver,
> if needed, just in =
> >case you want it I can send right away to you.
> >Besides: Did you know or know how to find out zeus3d
> sources besides the pu=
> >blic package?
> >
> >Thanks in advance
> >
> >--- El mi=E9, 20/4/11, Mika Nystrom <mika at async.caltech.edu>
> escribi=F3:
> >
> >> De: Mika Nystrom <mika at async.caltech.edu>
> >> Asunto: Re: [M3devel] wrapping postgresql library
> not enough
> >> Para: "Tony Hosking" <hosking at cs.purdue.edu>
> >> CC: m3devel at elegosoft.com
> >> Fecha: mi=E9rcoles, 20 de abril, 2011 22:20
> >> Aha, I will try that if it happens
> >> again.  I wrapped more things that I think
> >> might be iffy in my program.
> >>=20
> >> But I have a feeling ThreadPosix__DumpEverybody
> won't
> >> work... the
> >> application is probably deadlocked by having a
> single
> >> thread locking
> >> against itself with some sort of pthread
> lock.  I
> >> should look at the
> >> source code of free.
> >>=20
> >>      Mika
> >>=20
> >> Tony Hosking writes:
> >> >Can you dump all the user threads at this
> point?=20
> >> =3D
> >> >ThreadPosix__DumpEverybody() should do
> it.  We
> >> want to see where the =3D
> >> >other threads might be.
> >> >
> >> >On Apr 20, 2011, at 10:53 PM, Mika Nystrom
> wrote:
> >> >
> >> >> Hi again,
> >> >>=3D20
> >> >> So, as I described before, I wrote a
> program that
> >> wraps all of =3D
> >> >Critical
> >> >> Mass's "postgresql" library (PQ.i3) with
> >> Scheduler.DisableSwitching /
> >> >> Scheduler.EnableSwitching.  Yes, it
> seems to
> >> have reduced the =3D
> >> >frequency
> >> >> at which my application locks up, but it
> has not
> >> eliminated the =3D
> >> >lockups.
> >> >>=3D20
> >> >> User threads, AMD64_LINUX.
> >> >>=3D20
> >> >> I'm not quite sure what to try
> next.  How can
> >> I find out where malloc
> >> >> and free might be used reentrantly,
> assuming that
> >> is the problem?
> >> >>=3D20
> >> >> There may not be any reliable threading
> in CM3
> >> anymore.  Possibly it's
> >> >> reliable on FreeBSD (without -pthread)
> but I
> >> wouldn't bet money on it.
> >> >>=3D20
> >> >>     Mika
> >> >>=3D20
> >> >> (gdb) where
> >> >> #0  0x00007f7a8da0102e in ?? ()
> from
> >> /lib/libc.so.6
> >> >> #1  0x00007f7a8d99eb43 in ?? ()
> from
> >> /lib/libc.so.6
> >> >> #2  0x00007f7a8d99baab in free ()
> from
> >> /lib/libc.so.6
> >> >> #3  0x000000000077b08d in
> PQsendQuery ()
> >> >> #4  0x0000000000767c12 in
> >> PQSchedulerWrap__PQsendQuery (conn=3D3DCannot =3D
> >> >access memory at address 0x7f7b848a4298
> >> >> )
> >> >>    at
> >> ../AMD64_LINUX/PQSchedulerWrap.m3:210
> >> >> #5  0x0000000000763ce0 in
> >> UnsafeDatabase__MyExec (t=3D3DCannot access =3D
> >> >memory at address 0x7f7b848a4328
> >> >> ) at ../src/UnsafeDatabase.m3:92
> >> >> #6  0x0000000000764a29 in
> >> UnsafeDatabase__ExecM (t=3D3DCannot access =3D
> >> >memory at address 0x7f7b848a43f8
> >> >> ) at ../src/UnsafeDatabase.m3:239
> >> >> #7  0x0000000000764cee in
> >> UnsafeDatabase__TExecM (t=3D3DCannot access =3D
> >> >memory at address 0x7f7b848a4528
> >> >> ) at ../src/UnsafeDatabase.m3:269
> >> >> #8  0x0000000000756638 in
> >> DesynchronizedDB__TransSExec (trans=3D3DCannot
> =3D
> >> >access memory at address 0x7f7b848a45e8
> >> >> ) at ../src/DesynchronizedDB.m3:74
> >> >> #9  0x00000000005aeac6 in =3D
> >>
> >DBTable_gcoms_ordr_statusMonitor__ScanDirty__Attempt.1014
> >> =3D
> >> >(finalAttempt=3D3DCannot access memory at
> address
> >> 0x7f7b848a463f
> >> >> )
> >> >>    at
> >> ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3
> =3D3D>
> >> =3D
> >>
> >/home/mika/t/calarm/ratsql/src/TableMonitor.mg:41
> >> >> #10 0x00000000005ae639 in
> >> DBTable_gcoms_ordr_statusMonitor__ScanDirty =3D
> >> >(cl=3D3DCannot access memory at address
> 0x7f7b848a4778
> >> >> )
> >> >>    at
> >> ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3
> =3D3D>
> >> =3D
> >>
> >/home/mika/t/calarm/ratsql/src/TableMonitor.mg:73
> >> >> #11 0x00000000005b171e in =3D
> >> >DBTable_gcoms_ordr_statusMonitor__CheckForNew
> >> (cl=3D3DCannot access memory =3D
> >> >at address 0x7f7b848a4958
> >> >> )
> >> >>    at
> >> ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3
> =3D3D>
> >> =3D
> >>
> >/home/mika/t/calarm/ratsql/src/TableMonitor.mg:469
> >> >> #12 0x00000000005b1382 in
> >> DBTable_gcoms_ordr_statusMonitor__Sync =3D
> >> >(cl=3D3DCannot access memory at address
> 0x7f7b848a4ba8
> >> >> )
> >> >>    at
> >> ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3
> =3D3D>
> >> =3D
> >>
> >/home/mika/t/calarm/ratsql/src/TableMonitor.mg:445
> >> >> #13 0x00000000005b0e1c in
> >> DBTable_gcoms_ordr_statusMonitor__ApplyC =3D
> >> >(cl=3D3DCannot access memory at address
> 0x7f7b848a4d58
> >> >> )
> >> >>    at
> >> ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3
> =3D3D>
> >> =3D
> >>
> >/home/mika/t/calarm/ratsql/src/TableMonitor.mg:393
> >> >> #14 0x0000000000922eb5 in
> ThreadPosix__RunThread
> >> () at =3D
> >> >../src/thread/POSIX/ThreadPosix.m3:1174
> >> >> #15 0x00007f7a8d9697b0 in ?? () from
> >> /lib/libc.so.6
> >> >> #16 0x0000000000000000 in ?? ()
> >> >> (gdb)=3D20
> >> 
> 