Vm-dev

vm-dev@lists.squeakfoundation.org

10 participants
17030 discussions

Re: 3.7-7 "final" VM for Unix
by Ian Piumarta 21 Mar '05

21 Mar '05

> Nifty, so I downloaded it, check the instructions for building, and > take the easy way out by just typing "make". I'm on Mac OS X 10.3.8 > > /Users/todd/Projects/Squeak-3.7-7/platforms/unix/plugins/ > B3DAcceleratorPlugin/sqUnixOpenGL.h:26:7: #error *** cannot find gl.h > > So, what special value/place in this wonderfully elaborate build > system should we tweak to make this work out of the box for Mac users? For auto-detection of X11 library and header locations to work, you (an anonymous, generic 'you') must have /usr/X11R6/bin (or equivalent) in your PATH and you must have a working 'xmkmf' in that location. In other words: to build Squeak with X11 support your compilation environment must be capable of building X11 clients from source. (Sounds obvious when put like that, no?) Otherwise you can bypass X11 auto-detection by running configure manually: mkdir bld .../config/configure --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib make (assuming the required X11 headers and libraries are installed). If you get compilation errors after configuring with '--without-x' (including OpenGL-related errors on Mac OS X) then let me know, because you've found a real bug. Cheers, Ian PS: I only saw the above email because of a broken imap server. Send VM build problems to VM-Dev or to the maintainer of the affected VM. Thanks.

1 0

[VM][ENH][VMMaker] CPP directive translation for SLANG
by David T. Lewis 21 Mar '05

21 Mar '05

This change set adds support for the C preprocessor to SLANG. Two new methods are supported: Object>>cppDirective Object>>cppIfDef:inSmalltalk:comment:ifTrue:ifFalse: Examples: The Smalltalk expression: self cppDirective: 'ifdef HAS_FOO'. self doFooStuff. self cppDirective: 'endif'. is translated to: # ifdef HAS_FOO doFooStuff(); # endif The Smalltalk expression: self cppIfDef: 'HAVE_FOO' inSmalltalk: [if self haveFoo] comment: 'some platforms do not support foo properly' ifTrue: [self doThingsThatWorkIfFooIsPresent] ifFalse: [self doSomethingElseInstead]. is translated to: # ifdef SOMETHING // system supports foo doThingsThatWorkIfFooIsPresent(); # else doSomethingElseInstead(); # endif // SOMETHING Here is an example of a method that uses the C preprocessor: primitiveUnsetEnv "Unset an environment variable." | cStringPtr keyString | self export: true. self var: 'cStringPtr' declareC: 'char *cStringPtr'. keyString _ interpreterProxy stackObjectValue: 0. cStringPtr _ self transientCStringFromString: keyString. self cppIfDef: 'HAVE_UNSETENV' inSmalltalk: [true] comment: 'unsetenv() is not portable' ifTrue: [self unsetenv: cStringPtr] ifFalse: [interpreterProxy primitiveFail]. interpreterProxy pop: 1 The generated C code in the plugin is: EXPORT(int) primitiveUnsetEnv(void) { int keyString; char *cStringPtr; keyString = interpreterProxy->stackObjectValue(0); cStringPtr = transientCStringFromString(keyString); # ifdef HAVE_UNSETENV // unsetenv() is not portable unsetenv(cStringPtr); # else interpreterProxy->primitiveFail(); # endif // HAVE_UNSETENV interpreterProxy->pop(1); } Dave

1 0

RE: 3.7-7 "final" VM for Unix
by Todd Blanchard 20 Mar '05

20 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nifty, so I downloaded it, check the instructions for building, and take the easy way out by just typing "make". I'm on Mac OS X 10.3.8 I get this: gcc -g -O2 -O3 -mcpu=750 -funroll-loops -g -O2 -O3 -mcpu=750 - - -funroll-loops -DHAVE_CONFIG_H - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/unix/bld - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/unix/vm - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/Cross/vm - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/unix/bld - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/unix/vm - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/Cross/vm - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/Cross/plugins/FilePlugin - - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/Cross/plugins/ B3DAcceleratorPlugin - - -I/Users/todd/Projects/Squeak-3.7-7/platforms/unix/plugins/ B3DAcceleratorPlugin -I/usr/X11R6/include -c /Users/todd/Projects/Squeak-3.7-7/platforms/unix/vm-display-X11/ sqUnixX11.c -fno-common -DPIC -DPIC -o sqUnixX11.o In file included from /Users/todd/Projects/Squeak-3.7-7/platforms/unix/vm/SqDisplay.h:13, from /Users/todd/Projects/Squeak-3.7-7/platforms/unix/vm-display-X11/ sqUnixX11.c:74: /Users/todd/Projects/Squeak-3.7-7/platforms/unix/plugins/ B3DAcceleratorPlugin/sqUnixOpenGL.h:26:7: #error *** cannot find gl.h make[2]: *** [sqUnixX11.lo] Error 1 make[1]: *** [vm-display-X11.la] Error 2 make: *** [all] Error 2 doing a little finding in the /System directory yields [todd]/System/Library>find . -name gl.h ./Frameworks/AGL.framework/Versions/A/Headers/gl.h ./Frameworks/OpenGL.framework/Versions/A/Headers/gl.h So, what special value/place in this wonderfully elaborate build system should we tweak to make this work out of the box for Mac users? On Mar 19, 2005, at 4:45 PM, Ian Piumarta wrote: > Unix Hackers, > > I am pleased (and relieved) to announce the "final" 3.7-7 VM for Unix. > This VM is very close to 3.7b-5 (which has been working well for many > people for some time) with the addition of several critical fixes. > > Archives are in the usual place (http://squeak.hpl.hp.com/unix) for > sources and a few pre-compiled binaries: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCPQhlhullemWJdQ8RAlkXAJ9bkmmECn+z/nxLfiFW7+QQDNEynACgij4u yhE/751u4YjKKrPtrLs7aOw= =nKIO -----END PGP SIGNATURE-----

1 0

Mpeg3Plugin
by Ian Piumarta 20 Mar '05

20 Mar '05

The Mpeg3Plugin will not compile using vendor tools on Solaris. (One function is inlined out of existence, then referenced without declaration from within another file, causing the link to fail.) Unless someone objects within the next 30 minutes, I am committing a change to platforms/Cross/plugins/Mpeg3Plugin/libmpeg/video/motion.c as follows: -INLINE void mpeg3video_calc_dmv(mpeg3video_t *video, +#if !defined(sun) +INLINE +#endif +void mpeg3video_calc_dmv(mpeg3video_t *video, Time is now Sat Mar 19 12:28:26 PST 2005. You have until 12:58:26 to complain. Ian

2 1

Proposal: utf32Code in sqKeyboardEvent
by Andreas Raab 19 Mar '05

19 Mar '05

Folks, Since I'm not sure all of you have followed the discussion about scroll events (which then went into keyboard events) here's my proposal again: I would like to add a utf32Code field to sqKeyboardEvent which serves the purpose to provide a UTF-32 value if the VM provides extended input services (the Mac VM already does; others will surely follow). The utf32Code field only needs to be filled in for EventKeyChar events (e.g., neither for EventKeyDown or EventKeyUp since those are used for reporting keys not characters). John is already playing with this but I want to make sure there is general agreement on this issue. Ian, Tim? Any extra comments? Cheers, - Andreas

2 1

Scroll events
by Bert Freudenberg 19 Mar '05

19 Mar '05

Scroll events really should be mouse events (*). This hasn't been too much of a problem in Morphic where we have a focus-follows-mouse policy. But in Tweak, for example, the keyboard scroll events go to the focused pane even when I point the mouse somewhere else. AFAIK no host platform originally delivers scroll events as keyboard events, so it appears as the Right Thing to do, rather then hacking around it on the image side. However, I'm not sure about the best way to actually hand this to the image ... Any opinions? As a further data point, there are mice having both vertical and horizontal scroll capabilities, something that users may want to put to use. Not sure if we should support the additional buttons, too, but why not? My mouse has 8 of them in total, all of which do something reasonable - yes I'm on a Mac ;-) [OT] Rumor has it that Apple is going to introduce a new mouse soon, which may have two buttons or an iPod-like wheel or both ... - Bert - (*) Yes, I'm guilty for coming up with the arrow-key hack in the first place, but it was TSTTCPW

7 20

Unix 3.7 gamma VM
by Ian Piumarta 18 Mar '05

18 Mar '05

Folks, I thought I'd put out a 'gamma' before releasing the final 3.7. Archives of binaries and sources are available from the (new) usual place: http://squeak.hpl.hp.com/unix/ The same sources can be checked out from our Subversion repository, if you prefer: svn co http://squeak.hpl.hp.com/svn/squeak/tags/unix-3.7g-6 If there are no show-stoppers in the next 24 hours or so I'll promote it to 3.7-7 'final' and begin pulling in lots of new stuff for 3.8... Thanks, Ian

9 24

Issue tracking
by Bert Freudenberg 17 Mar '05

17 Mar '05

Isn't "issue" a much nicer word than "bug"? ;-) Anyway, I think it would make sense to create a specific tracker for VM issues like bugs, feature requests etc. We could easily add one to our mantis setup. This would also make it easy to move requests from "Squeak" or "Tweak" to "VM" if appropriate. - Bert -

1 0

Re: VM "team"
by Ned Konz 17 Mar '05

17 Mar '05

On Thursday 10 March 2005 11:34 pm, goran.krampe(a)bluefish.se wrote: > Ian wrote: >> I was also very clear, when we first adopted SF, that CVS was a >> periodic backup of my source tree (and not the primary copy) and that the >> only de-facto set of sources were in tarballs on my download page. > > Well, ok, but even if you made that clear it was never clear to a lot of us > I think. Or at least a lot of us falsely presumed that the CVS repo was > intended to be the master place. So again, I repeat - these kinds of things > should IMHO be documented shortly and distinctly in a single place. I would > like someone to do that, is that something you all agree with? Then I assume > that this is not going to be the case from now on. The fact that stuff is > being touched on Svn doesn't really tell me a thing in this regard, stuff > was touched on SF too, but it was still not considered the "master site" of > the unix source. There are advantages and disadvantages to making the > repository be the primary copy of my sources. I haven't decided yet. Ok, now > - I of course respect each and every port maintainer to make their own > decisions regarding their ports (it is after all your code :)) - but let me > just point out that what you now write is not known. I was under the > distinct impression Andreas just told me that Svn is the master. Would it be too much to ask that all the "official" VM maintainers commit to some common practice and start trying to work together? Why bother setting up a private repository if we're not going to use it? I respect that different primary maintainers may have different preferred ways to work, and different schedules. However, given that SVN is quite powerful and flexible, can't we just agree to certain basic strategies? This is a community, and if we really want to have others help with fixes and enhancements, wouldn't it be better to make ongoing development actually public and in one place? My proposal is this (yes, I know it will mean that we will have to change the way we work): * Ongoing development on shared code (VMMaker, platforms/Cross) and on "official" platform code is kept updated on SVN. Even if there is only a single developer working on the main development branch of a particular platform, they should keep the repository updated as often as they feel that they have a version that can be built and tested by others. * There is a single branch for the 'main' development branch of each platform. The "Cross" branch also has a primary platform developer (Tim?). The primary platform developer has admin control over this branch. So we'd have: /trunk platforms Cross (platform-independent) unix MacOs Win32 etc. * All VM maintainers who have declared an interest in doing development, have been accepted by the primary maintainers, and agree to follow the rules have the ability to create their own branches for experimental work (their own extensions, etc.). These are not meant as forks of the main platform branches; if you're working on platform code you should be communicating with the rest of the platform team. /branches EXP-ned-cairo platforms EXP-craig-flow platforms etc. * Acceptance of code into the official platform branches is decided by the primary platform maintainer. * VMMaker sources and/or distributions are also maintained under SVN control, and is in sync with each of the branches that it appears on. This way someone can get a particular branch in its entirety, and have the entire package needed to build and test coherent sources. * Additional platform- or plugin-specific Squeak code, documentation, test code, scripts, demos, etc. should also be maintained on SVN, together with the plugin or platform code that it works with. For instance, it's typical that an optional plugin may have Squeak code to actually make it work. So for instance (say for the OSProcess plugin): /trunk platforms Cross plugins OSProcess unix plugins OSProcess * Tags should be used to mark buildable, testable versions of code/VMMaker combinations for each branch. This goes for both released versions and interim development versions that are known to be buildable and work well enough to be testable. This way we can talk about a particular version using something other than the version number. So: /tags REL-Win32-3.6b-2 REL-unix-3.7b-5 DEV-unix-2005-05-07 etc. * There is no hard-and-fast requirement that the trunk be buildable, but it makes sense to make a reasonable effort to have the trunk mirror something that is known to build. * Official releases are first published as tags on SVN. If further packaging is needed (like making .deb packages, packages including tools, etc.) then that is done later. This * When sub-teams (or even individual developers) are doing experimental work, they should let the vm-dev list know, just in case someone else is also working on the same thing (or has in the past). They should be encouraged to update the SVN repository from time to time. -- Ned Konz http://bike-nomad.com/squeak/

5 4

Re: VM "team"
by goran.krampe＠bluefish.se 16 Mar '05

16 Mar '05

Hi Ian! (moved to vm-dev) Ian Piumarta <ian.piumarta(a)hp.com> wrote: > On Mar 15, 2005, at 13:23, goran.krampe(a)bluefish.se wrote: > > > And it is a bit frustrating, AFAIK it still isn't in there > > (getImageName). So the unix HEAD isn't compiling with the current > > VMMaker > > It's compiling fine with the VMMaker shipped with 3.7-5898-full. Ehum, cough. Ok, now the fog clears. :) I didn't notice VMMaker is already included in 3.7, so I opened up SMLoader in a 5989-full, selected VMMaker and installed it. Oops, bad move. That will install the latest, which evidently is a beta for 3.8, but in this case unfortunately marked as being for 3.7 (so SM will not complain), though even if it tripped me up, that may be considered fine - since it does after all *work* in 3.7. I apologize for my utter VM-n00b-stupidity and still humbly conclude that a little page somewhere explaining how to do this properly would at least have helped me - and obviously all the other people stumbling on this getImageName stuff - evidently they must all have been falling in the same trap. :) I know Ian has pretty detailed and good descriptions, but I think what is lacking here is a more condensed howto that indeed includes this stuff about VMMaker (haven't tested this, but I guess you see what I mean): - Get the full image for the official *current release*. - Use the VMMaker installed in that image, or install the latest version *for that release* (not newer). The trunk of the support code is meant to build with the *released* VMMaker, not with the latest available. - Check out trunk like this: yaddayadda - Create configure script by doing: cd <somewhere>/squeak/platforms/unix/config ./configure && make - Start VMMaker and set platforms path to "<somewhere>/squeak/trunk/platforms" and src path to "<somewhere>/squeak/trunk/src" (which you need to create) - Then create directory <somewhere>/squeak/trunk/build After that this should repeatedly build you a VM: - Use VMMaker: Clean out source (the button) Make all plugins internal (or start with none) Generate all - cd to <somewhere>/squeak/trunk/build and build it: rm -rf * && ../platforms/unix/config/configure && make And to install, you can do make install etc. See Makefile for other targets like for example only compiling plugins etc. regards, Göran PS. Ian, did you try with automake 1.8 or 1.9? PSS. Still think a little page explaining the most important details about the VM work process would be helpful. I don't think many people are aware that Ian wants patches in the form of full files sent by email for example.

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev