Feeds:
Posts
Comments

Archive for the ‘project’ Category

Here are the command line commands I used to get CogSpur running with a VMMaker image and the CMakeVMakerSqueak package starting from scratch.

#Do an svn checkout

svn co http://www.squeakvm.org/svn/squeak/branches/Cog

#run Eliot’s bash script to get the VMMaker image up and configured.

cd Cog/image
cat README
./ buildspurtrunkvmmakerimage.sh
./ cogspurlinuxht/squeak  SpurVMMaker.image  &

#Install the CMakeVMMakerSqueak package and see the documentation
Monticello browser
Repository http://source.squeak.org/VMMaker
CMakeVMMaker (latest) load
CMakeVMMakerSqueak (latest) load
HelpBrowser topic CMakeVMMakerSqueak

save and quit

#set up my personal working environment

#put the executable cog/spur in my PATH

mv cogspurlinuxht /home/tty/usr/bin/

#set up a development area independent of the Cog svn source tree
cd ../../
mkdir cogspurVMMaker
mv Cog/image/SpurVMMaker.* cogspurVMMaker/
mv Cog/image/SqueakV50.sources cogspurVMMaker/

#the tools are installed. now we need to put the Cog source tree
#in a subdirectory of the .image file. The directory is named ‘oscogvm’

cd cogspurVMMaker
mkdir oscogvm
rsync -Carv  –exclude=”image*”  ../Cog/ cogspurVMMaker/

#the resulting work environment directory tree looks like this

tree -d -L 2  cogspurVMMaker/
cogspurVMMaker/
`– oscogvm
|– build.linux32ARM
|– build.linux32x86
|– build.linux64x64
|– build.macos32x86
|– build.macos64x64
|– build.win32x86
|– history
|– nsspursrc
|– nsspurstack64src
|– nsspurstacksrc
|– nssrc
|– platforms
|– processors
|– products
|– scripts
|– sources
|– spur64src
|– spursistasrc
|– spursrc
|– spurstack64src
|– spurstacksrc
|– src
`– stacksrc

 

Advertisements

Read Full Post »

Building SqueakSSL compiles just fine, but fails at the libtool stage when compiled as an internal plugin.

My hunch is that when compiled as an external plugin, the linking is deferred until the module is loaded by the VM. If that is the case, then it explains the primitive fail.

My approach was to compile it as an internal plugin as (by just giving it a try) I found what I thought was an #include error. It took me a while (too long really–I have a bad habit of not closely reading things) find the problem, but it happens after a successful compilation when a thing called “libtool” is run.

Here is the output of the error at that stage:

/bin/sh
[......]/debugCogSqueakSSL/unixbuild/bld/libtool --mode=link gcc -m32 -g -Og -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DCOGMTVM=0 -DDEBUGVM=0 -DLSB_FIRST=1 -Wl,-z,now -export-dynamic -o squeak vm/vm.a AsynchFilePlugin/AsynchFilePlugin.a B2DPlugin/B2DPlugin.a BitBltPlugin/BitBltPlugin.a FilePlugin/FilePlugin.a SocketPlugin/SocketPlugin.a SqueakSSL/SqueakSSL.a MiscPrimitivePlugin/MiscPrimitivePlugin.a disabledPlugins.o version.o -lutil -ldl -lpthread -lm -lnsl -lpthread vm/vm.a

gcc -m32 -g -Og -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DCOGMTVM=0 -DDEBUGVM=0 -DLSB_FIRST=1 -Wl,-z -Wl,now -o squeak disabledPlugins.o version.o -Wl,--export-dynamic vm/vm.a AsynchFilePlugin/AsynchFilePlugin.a B2DPlugin/B2DPlugin.a BitBltPlugin/BitBltPlugin.a FilePlugin/FilePlugin.a SocketPlugin/SocketPlugin.a SqueakSSL/SqueakSSL.a MiscPrimitivePlugin/MiscPrimitivePlugin.a -lutil -ldl -lpthread -lm -lnsl -lpthread vm/vm.a

SqueakSSL/SqueakSSL.a(sqUnixOpenSSL.o): In function `sqCopyBioSSL':
[......]/debugCogSqueakSSL/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.c:37: undefined reference to `BIO_ctrl_pending'

(more errors omitted for brevity. all of them are unresolved references to stuff in /usr/include/openssl/ssl.h . these errors do not happen at compile time, only linking stage )

Since discovering this, I have tried two things

1. compile on my pure 64 bit partition…this failed –we don’t have 64 bit Cog yet (: but hey…a guy can hope!

2. I installed openssl compat32 libs alongside the 64 bit versions…as shown below.
2.a I made some changes that I kinda-sorta-hoped would work in some strings in the script that had the substring “/lib64 ” but that did not work.

bash-4.2$ ls lib/*ssl*
lib/libssl.so.0 lib/libssl.so.0.9.8 lib/libssl.so.1 lib/libssl.so.1.0.0
bash-4.2$ ls lib64/*ssl*
lib64/libssl.so.0 lib64/libssl.so.0.9.8 lib64/libssl.so.1 lib64/libssl.so.1.0.0

I posted the above to the vm-dev mailing list and will see if anybody picks up on it. I will hit this again tomorrow!

Read Full Post »

Since my compile of Cog is not working and is going to take some more work and understanding, I decided to strip things down to the bare minimum and work upwards.

One of the things that has been on my list of ‘todos’ for a while is understanding the layout of the various Smalltalk distrobutions–Pharo, Croquet, Squeak etc.

This morning, I am documenting everything I see and don’t understand in the directory structure of these applications. I just finished documenting the Pharo directory tree and am currently documenting the Squeak4.2-All-in-one.app structure and then I will probably do the Croquet and OpenCobalt trees just for completeness (gotta throw PhysicalEToys in there too, I guess (:)

A first lesson is that it seems a distribution is a platform for distributing on Mac, Dos and Linux concurrently–with a bulk of the files being geared towards the Mac.

For example, .plist files are Mac files as are .dylib files. Whether or not they are used by the other systems is something I will be investigating.

Furthermore, it seems that .dylib files co-respond to .bundles.

Anyway, that is the project, I will write when I know more.

Read Full Post »

I am running Slackware64 version 13.37 on an AMD 6 Core processor.

These steps are from: http://connie.slackware.com/~alien/multilib/

  1. lftp -c ‘open http://slackware.com/~alien/multilib/ ; mirror 13.37’
  2. cd 13.37;ls
  3. upgradepkg –reinstall –install-new *.t?z
  4. cd slackware64-compat32/;ls
  5. upgradepkg –install-new *-compat32/*.t?z
  6. done?
  7. Running 32-bit Squeak on a 64-bit System. Hope the 32-bit runtime libraries are installed …
    Segmentation fault
  8. sigh.
  9. reboot (linking? ldd stuff?)
  10. hmmm…

Ok, none of my vm’s–pharo, cog, squeak4.3–worked except one–Physical EToys (yay!!!!)

I navigate to the
/PhysicalEtoys.1.7/Contents/Linux-i686
and request the version from the squeakvm and get the following:

bash-4.1$ ./squeakvm -version
3.11.3-2144 #1 XShm Tue Sep 29 09:27:17 ART 2009 gcc 4.3.3
Linux caeti-ubuntu 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux
plugin path: /home/wm/usr/src/smalltalk/PhysicalEtoys.1.7/Contents/Linux-i686/ [default: /home/wm/usr/src/smalltalk/PhysicalEtoys.1.7/Contents/Linux-i686/]

the contents of that directory look different from my other distros:


bash-4.1$ ls
Info.plist so.ClipboardExtendedPlugin so.KedamaPlugin so.PseudoTTYPlugin so.XDisplayControlPlugin so.vm-display-null
PkgInfo so.FileCopyPlugin so.KedamaPlugin2 so.Squeak3D so.vm-display-X11 so.vm-sound-custom
libparallel.so.1.0.1 so.HostWindowPlugin so.MIDIPlugin so.SqueakFFIPrims so.vm-display-custom so.vm-sound-null
so.AioPlugin so.ImmX11Plugin so.Mpeg3Plugin so.UnixOSProcessPlugin so.vm-display-fbdev squeakvm

hmmmm…

Well, one is working.

I am going to try compiling the stuff per Mariano’s blog.

ciao for now.

Read Full Post »

I have my new machine and none of my smalltalk vm’s work on it. My hunch is I need to install slackware64 compatability libraries.

Before I do that, I am reading through http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-using-git-and-cmakevmmaker/

With 64 bit machines rapidly becoming the new normal, I need to get fluent in this.

Should be a bit of a slog, but that’s how we learn (:

Update: Mariano Peck was kind enough to wish me luck with a comment. Thanks!

Update: I started reading Mariano’s post and it became clear to me that he is using CMake to manage his project (Which is evident from his blog post title, but being a bit dense, I missed that (: ). CMake does not appear to support IA64 Bit native architecture, which explains why the compatibility libraries are needed. So, my focus needs to be on simply installing the compatibility libraries for Slackware 64. When I get that done, I will post a quick mini-howto on it.

Before I do that, however, I must say that the process of compiling and generating a VM appears to be very interesting. I will be returning to this another time when I get a few of my current projects done. My impression (and it is only that) is that a Smalltalk/Cog system is composed of the operating system ‘interface’ code which is managed in the CMake project and a corresponding Smalltalk project that is managed with VMMaker (which I am not familiar with). If this is correct, then this project I have in the back of my mind for uncoupling Smalltalk from its native Morphic interface may have to happen there via a plug-in. I also have an idea to provide Emacs hooks to the VM, so I can code Squeak from Emacs. Those ideas are all pie-in-the-sky until I get good at this stuff.

Anyway the task at hand is to get the (correct?) compatibility libraries installed so I can get back to my current Smalltalk projects on my new 64 bit computer!

Update: Looking at Physical EToys, it uses pre-compiled squeak v 3.x, so my strategy of building their build locally and figuring out the differences goes by the wayside.What I am going to do now is investigate the older squeaks, make sure they run, and then try to build those.

Update: When browsing for an older squeak, I re-ran across the fact that 64 bit VM’s exist that can run natively on 64 bit machines. The issues are that most plugins are compiled for 32 bit machines. Since I am going to be in build compile mode for a while, I will be investigating this as well.

Read Full Post »

Still Here.

My HLA work will continue, I am taking some time to regroup and take care of some basics.

My approach of reverse engineering Certi is the wrong approach to take. C/C++ and Smalltalk involve very different styles of thinking and I found the C-isms where an obstacle to what I want to achieve.

Happily, I was able to get the tests to run on Open HLA which is a java implementation of HLA.

My idea is to duplicate the tests in Smalltalk first (Always write your tests first* ). I am also investigating joining IEEE and buying the specs as well.

I am also taking some time to put in place some foundations that I am missing. For example, I got the Squeak By Example LateX source to compile and output the pdf version of the book. I will be leveraging that framework to document HLA as I go. (Frankly, I need the ongoing documentation, because it is a big subject).

I am also taking the time to become a better Smalltalker. There are entire areas of the system that I am a newbie in and that detracts from the HLA project as well. Specifically, Networking, XML, Morphic, Tweak (?), Help System, Tests and Math are the areas I need to become good at. Having taken the time to get Squeak By Example to compile, I can document each area in an ongoing manner.

With all that, there is the matter of my day job and some other projects I have going concurrently (Arduino, Zend).

*Steve Wessels seems to code them right after he defines the instance variables for his classes. I am finding it to be a good routine to have as I learn his tutorial

Read Full Post »

My bad.

I am re-starting with the new Squeak 4.2 and when I tried to import my packages, they where broken. I have since deleted them. They will be re-submitted as Meta-Cello packages.

I am currently learning the squeak help system and will be making that the second step in my releases.

Step 1. tests
Step 2. help written
Step X….

I am very embarrassed.

Read Full Post »

Older Posts »