Is it possible to build OpenSmalltalk VM for OpenBSD? If yes, how? If no, is there any other solution available? OpenBSD ports for 6.4 for AMD64 has only the 3.10-1 version available. — |
I haven't worked with building the VM on OpenBSD, but I see this past discussions... So there seem two places to review... Now it would be really great if you could create folders build.openbsd32x86 and build.openbsd64x64 to work in to merge the stuff the two urls above - to make it easier for the next person. If files/folders need to be organised into a particularly way for OpenBAD Ports, it would be good to have a script to do that to convert from the standard opensmalltalk-vm folder arrangement. — |
In reply to this post by David T Lewis
Hey the Cog branch should build on OpenBSD. No need to make a dedicated openbsd folder, just use the linux one(s). Note that the VM is not w^x compatible, nor mapstack, neither unveil. — |
In reply to this post by David T Lewis
I wont push this point, but just to share a thought... One benefit of a dedicated folder is that it "advertises" the availability of a OpenBSD. It helps potential users "feel" more confident about trying it. There will be a percentage of people who came looking, didn't see any reference and just moved on without asking. If you don't want separate folders for Free/Net/Open-BSD, perhaps a build.bsd64x64 folder would be appropriate? — |
In reply to this post by David T Lewis
well, it even could be unix bla Maybe have a different issue for that? — |
In reply to this post by David T Lewis
Can you do the build scripts less Bash? Or even better, can use Makefiles for that? — |
In reply to this post by David T Lewis
I understand your point. We've had a lot of discussing about the whole build infrastructure and as it stands, it currently works for all the major dists we can support; moreover at the moment we have to focus on other parts of the VM. That means that the build infra (directories, bash, etc) will stay as is until we have enough manpower and consesus to find a more universal solution. That being said, opensmalltalk-vm works and compiles on OpenBSD. If anyone steps up making an upgrade to the port, all PRs are welcome. — |
In reply to this post by David T Lewis
Take a look: — |
In reply to this post by David T Lewis
@asarch I have re-run your build on OpenBSD 6.4 and cannot reproduce. Btw, do you really want to build a newspeak VM? I suggest starting with a plain squeak vm, which would mean starting ins
Also, make sure that you run squeak on a # mount
/dev/sd0a on / type ffs (local, wxallowed) — |
In reply to this post by David T Lewis
Does it need to be root for compilation? Here is my
The mounted partitions:
What's wrong? — |
In reply to this post by David T Lewis
It is missing OpenSmalltalk-VM needs wxallowed to run, at the moment. — |
In reply to this post by David T Lewis
Ok, after doing a So, If used the Squeak5.2-18229-64bit.image, Squeak5.2-18229-64bit.changes and SqueakV50.sources from http://squeak.org/ and this is what I have now: One last question: how do you install it? — |
In reply to this post by David T Lewis
* asarch <[hidden email]> [190810 19:26]: > Ok, after doing a `dd if=/dev/zero of=/dev/rsd0c bs=1m count=1` by mistake in order to create a **vnconfig** device for compilation and restoring the entire system, I have: > > [output.log](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/3489145/output.log) > > So, If used the Squeak5.2-18229-64bit.image, Squeak5.2-18229-64bit.changes and SqueakV50.sources from **http://squeak.org/** and this is what I have now: > > ![Screenshot from 2019-08-10 12-23-06](https://user-images.githubusercontent.com/906401/62824967-e89bde00-bb69-11e9-9857-0b4ad6f75a3f.png) > > One last question: how do you install it? I have the repo in /usr/local/smalltalk. You should need to copy the respective product/ subdir to a place with the wxallowed bit set. I do keep the whole git repo there though and occasionally update and set my PATH accordingly. You could have a look at the outdated squeak port for inspiration on the proper install locations but IDK whether that's worth the hassle tbh. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. — |
In reply to this post by David T Lewis
Thank you! Thank you very much for all guys. — |
In reply to this post by David T Lewis
@asarch Great to see it working for you. — |
In reply to this post by David T Lewis
On the contrary, thank you, thank you very much for your patience and your time. Thank you. P.S. Just one last issue if I may, how would you compile the image from sources?: http://files.squeak.org/sources_files/SqueakV50.sources.gz — |
> On 2019-08-13, at 11:11 AM, asarch <[hidden email]> wrote: > > On the contrary, thank you, thank you very much for your patience and your time. Thank you. > > P.S. > > Just one last issue if I may, how would you compile the image from sources?: That's just not how it works. It *is* possible to build an image from a prescriptive definition - some folk on the Pharo list did a version last year I think, and Alejandro did a related project around '03 and I did some stuff and Craig has done a bunch of related stuff. But as a normal thing it simply doesn't mean anything. We have an image, we modify it and save it and start it, rinse and repeat. Dave Ungar pointed out many years ago that Smalltalk is saved but not born again. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim fallacio (n): speaking logical fallacies |
Pharo since version 7.0 is bootstrapped on every build. And it is surely the best way to get a reliable artefact Have a look at https://github.com/pharo-project/pharo/tree/Pharo8.0/bootstrap Norbert
|
In reply to this post by David T Lewis
Nice quote. — |
In reply to this post by David T Lewis
Norbert writes:
The approach you cited uses a plethora of external tools processing source code. That's composition, but not bootstrapping (something building itself, or "pulling itself up by its own bootstraps"). Whether you consider the essence of the system to reside in that source code or in machine instructions, reliability comes from being able to explain why each bit in the resulting artifact is there. I think that process is most understandable, and most effectively verified, when the space of those external tools is smallest. This is why I prefer systems that actually do bootstrap. -C — |
Free forum by Nabble | Edit this page |