A new Squeak release

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A new Squeak release

Eliot Miranda-2
Hi All,

    we're moving close to a new Squeak release.  There are some issues to discuss before we decide  exactly what and when to release.  I have two issues that I would like people's opinions on.

1. the VM can be compiled with support for read-only objects, and indeed Pharo is already doing this.  Were we to enable read-only object support we could introduce read-only bindings.  I have this code ready to go, but the current Squeak VM does not include read-only object support.  We could go ahead and release without read-only object support or enable read-only object support in the VM, push the new VMs out and enable read-only literals.  It would then take a few days for everyone to test their code and fix issues with read-only literals.  For example, code such as

a := { 'one ' . 'two ' . 'three ' }.
a do: [:e | e at: e size put: (Character value: 0)].

must be rewritten, e.g. as

a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll: Character space asString with: Character null asString].

and the classic

'' writeStream

as

'' copy writeStream

i.e. literals are read-only but copies of literals are not.

2. the current VM, Monticello and the ClassBuilder has full support for ephemerons, which provide instance based finalization. For example, if a file that is the key of some ephemeron in a registration dictionary, then, with a suitable finalization process, the VM will arrange that the ephemeron gets sent finalize when the file is only referenced from ephemeris, and then the ephemeron can finalize the file itself, flushing any buffered characters and closing the file's descriptor. What we have now is a copy of the file in a weak registry, which means we finalize the copy not the actual file. This limits our ability to write clean file implementations. The same applies to several other uses of weak registries. Again Pharo is using the facility (and hence we can use their finalization process and some of their code).

So the question is should we hold up the release for these features or should we go ahead and somehow arrange that we do address these (and other?) issues promptly in a subsequent release?

Let me make a proposal. We go ahead and make a release with what we have, calling it Squeak 5.5, and then follow a plan to provide read-only object support, read-only literals, and as mush of the finalizationsystem rewritten to use ephemeron (where appropriate) as we can manage by, say, September 1. This will be Squeak 6. And the trunk process would update to requiring a rad-only-object enabled VM immediately after the 5.5 release.

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

David T. Lewis
According to our web site, the current release is Squeak 5.1, and trunk
is Squeak 6.0alpha.

I think it has been about a year since the last official release, and
a lot of great stuff has gone into trunk during that time. So it would
be good to put out an official release some time soon. For that we should
identify a person to serve as release manager to make it happen. I expect
we will discuss this in our board meeting next week, but input (and volunteers
or nominations) from anyone in the community would certainly be welcome.

If we do something in the near term, then it would make sense to me if
it was called Squeak 5.2. And if that happens, it would be good to incorporate
full support for ephemerons and read only objects into whatever release
comes next after that.

In the mean time, my view would be that any changes for support of read
only objects and ephemerons should be introduced as soon as possible
regardless of the release schedule, just as long as this can be done
without requiring incompatible VM changes. I'm not quite clear on whether
that is the case here. But basically what I am trying to say is let's
move this forward as quickly as possible. If it is a change that would
cause pain for general users of Squeak, then hold off until after then
next release, and let's make sure that next release happens soon.

So +1 for your proposal, but maybe call it 5.2 rather than 5.5, and let's
find a release manager and make it happen.

And just so we do not forget - The last release was still focused on
32 bit images. The 64 bit system is not longer experimental, so we need
to publicize this better in our next release and document the limitations
so that users are aware that they will not be able run their 64 bit image
on a 32 bit platform.

Dave

On Thu, Mar 01, 2018 at 09:57:52AM -0800, Eliot Miranda wrote:

> Hi All,
>
>     we're moving close to a new Squeak release.  There are some issues to
> discuss before we decide  exactly what and when to release.  I have two
> issues that I would like people's opinions on.
>
> 1. the VM can be compiled with support for read-only objects, and indeed
> Pharo is already doing this.  Were we to enable read-only object support we
> could introduce read-only bindings.  I have this code ready to go, but the
> current Squeak VM does not include read-only object support.  We could go
> ahead and release without read-only object support or enable read-only
> object support in the VM, push the new VMs out and enable read-only
> literals.  It would then take a few days for everyone to test their code
> and fix issues with read-only literals.  For example, code such as
>
> a := { 'one ' . 'two ' . 'three ' }.
> a do: [:e | e at: e size put: (Character value: 0)].
>
> must be rewritten, e.g. as
>
> a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll: Character
> space asString with: Character null asString].
>
> and the classic
>
> '' writeStream
>
> as
>
> '' copy writeStream
>
> i.e. literals are read-only but copies of literals are not.
>
> 2. the current VM, Monticello and the ClassBuilder has full support for
> ephemerons, which provide instance based finalization. For example, if a
> file that is the key of some ephemeron in a registration dictionary, then,
> with a suitable finalization process, the VM will arrange that the
> ephemeron gets sent finalize when the file is only referenced from
> ephemeris, and then the ephemeron can finalize the file itself, flushing
> any buffered characters and closing the file's descriptor. What we have now
> is a copy of the file in a weak registry, which means we finalize the copy
> not the actual file. This limits our ability to write clean file
> implementations. The same applies to several other uses of weak registries.
> Again Pharo is using the facility (and hence we can use their finalization
> process and some of their code).
>
> So the question is should we hold up the release for these features or
> should we go ahead and somehow arrange that we do address these (and
> other?) issues promptly in a subsequent release?
>
> Let me make a proposal. We go ahead and make a release with what we have,
> calling it Squeak 5.5, and then follow a plan to provide read-only object
> support, read-only literals, and as mush of the finalizationsystem
> rewritten to use ephemeron (where appropriate) as we can manage by, say,
> September 1. This will be Squeak 6. And the trunk process would update to
> requiring a rad-only-object enabled VM immediately after the 5.5 release.
>
> _,,,^..^,,,_
> best, Eliot

>


Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Edgar De Cleene
On 01/03/2018, 23:17, "David T. Lewis" <[hidden email]> wrote:

> For that we should
identify a person to serve as release manager to make it
> happen. I expect
we will discuss this in our board meeting next week, but
> input (and volunteers
or nominations) from anyone in the community would
> certainly be welcome

I'm could be that person.

Edgar
@morplenauta




Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

K K Subbu
In reply to this post by Eliot Miranda-2
Is there a plan to spin out Squeak (the ST VM) from Squeak (the image)
in this (or subsequent) release cycle? or will the two releases go
hand-in-hand forever?

Now that the same VM is used by multiple (image) projects like Scratch,
Etoys, Pharo, Cuis and with binary variants like 32bit/64bit, cog/spur
etc. putting the VM on a separate cycle may be easier than linking it
with Squeak project releases. The VM may continue ship with a built-in
image for bootstrapping other images or for VMMaker but that need not be
linked with the latest Squeak release.

Regards .. Subbu

On Thursday 01 March 2018 11:27 PM, Eliot Miranda wrote:

> Hi All,
>
>      we're moving close to a new Squeak release.  There are some issues
> to discuss before we decide  exactly what and when to release.  I have
> two issues that I would like people's opinions on.
>
> 1. the VM can be compiled with support for read-only objects, and indeed
> Pharo is already doing this.  Were we to enable read-only object support
> we could introduce read-only bindings.  I have this code ready to go,
> but the current Squeak VM does not include read-only object support.  We
> could go ahead and release without read-only object support or enable
> read-only object support in the VM, push the new VMs out and enable
> read-only literals.  It would then take a few days for everyone to test
> their code and fix issues with read-only literals.  For example, code
> such as
>
> a := { 'one ' . 'two ' . 'three ' }.
> a do: [:e | e at: e size put: (Character value: 0)].
>
> must be rewritten, e.g. as
>
> a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll:
> Character space asString with: Character null asString].
>
> and the classic
>
> '' writeStream
>
> as
>
> '' copy writeStream
>
> i.e. literals are read-only but copies of literals are not.
>
> 2. the current VM, Monticello and the ClassBuilder has full support for
> ephemerons, which provide instance based finalization. For example, if a
> file that is the key of some ephemeron in a registration dictionary,
> then, with a suitable finalization process, the VM will arrange that the
> ephemeron gets sent finalize when the file is only referenced from
> ephemeris, and then the ephemeron can finalize the file itself, flushing
> any buffered characters and closing the file's descriptor. What we have
> now is a copy of the file in a weak registry, which means we finalize
> the copy not the actual file. This limits our ability to write clean
> file implementations. The same applies to several other uses of weak
> registries. Again Pharo is using the facility (and hence we can use
> their finalization process and some of their code).
>
> So the question is should we hold up the release for these features or
> should we go ahead and somehow arrange that we do address these (and
> other?) issues promptly in a subsequent release?
>
> Let me make a proposal. We go ahead and make a release with what we
> have, calling it Squeak 5.5, and then follow a plan to provide read-only
> object support, read-only literals, and as mush of the
> finalizationsystem rewritten to use ephemeron (where appropriate) as we
> can manage by, say, September 1. This will be Squeak 6. And the trunk
> process would update to requiring a rad-only-object enabled VM
> immediately after the 5.5 release.
>
> _,,,^..^,,,_
> best, Eliot
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

fniephaus
Hi all,

On Fri, Mar 2, 2018 at 11:30 AM K K Subbu <[hidden email]> wrote:
Is there a plan to spin out Squeak (the ST VM) from Squeak (the image)
in this (or subsequent) release cycle? or will the two releases go
hand-in-hand forever?

I always thought it was clear that with OpenSmalltalk release, I meant the VMs and not a new Squeak release. But it looks like people thought I was talking about a new Squeak release, thus Eliot's email I guess. Sorry for the confusion, my bad!
I do agree that there should be a new Squeak release rather sooner than later, but I am still interested in having a new checkpoint for the VMs soon. This helps us to find out how stable current Squeak VMs are and it's also useful for things like CI.
 

Now that the same VM is used by multiple (image) projects like Scratch,
Etoys, Pharo, Cuis and with binary variants like 32bit/64bit, cog/spur
etc. putting the VM on a separate cycle may be easier than linking it
with Squeak project releases. The VM may continue ship with a built-in
image for bootstrapping other images or for VMMaker but that need not be
linked with the latest Squeak release.

Those are some reasons why I think it would make sense to decouple the release processes for both the vm and the image. Why couple a new vm release to a Squeak or Pharo release if we could independently make new vm releases and then dialects can use the version they want or need. Maybe, this way we can fix VMs bugs without having to prepare a new image release: treat image and vm versions independently and only say "Squeak-5.x" needs "OpenSmalltalkVM Y or later" (assuming Squeak releases happen before breaking vm changes, such as Spur support).

Best,
Fabio
 

Regards .. Subbu

On Thursday 01 March 2018 11:27 PM, Eliot Miranda wrote:
> Hi All,
>
>      we're moving close to a new Squeak release.  There are some issues
> to discuss before we decide  exactly what and when to release.  I have
> two issues that I would like people's opinions on.
>
> 1. the VM can be compiled with support for read-only objects, and indeed
> Pharo is already doing this.  Were we to enable read-only object support
> we could introduce read-only bindings.  I have this code ready to go,
> but the current Squeak VM does not include read-only object support.  We
> could go ahead and release without read-only object support or enable
> read-only object support in the VM, push the new VMs out and enable
> read-only literals.  It would then take a few days for everyone to test
> their code and fix issues with read-only literals.  For example, code
> such as
>
> a := { 'one ' . 'two ' . 'three ' }.
> a do: [:e | e at: e size put: (Character value: 0)].
>
> must be rewritten, e.g. as
>
> a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll:
> Character space asString with: Character null asString].
>
> and the classic
>
> '' writeStream
>
> as
>
> '' copy writeStream
>
> i.e. literals are read-only but copies of literals are not.
>
> 2. the current VM, Monticello and the ClassBuilder has full support for
> ephemerons, which provide instance based finalization. For example, if a
> file that is the key of some ephemeron in a registration dictionary,
> then, with a suitable finalization process, the VM will arrange that the
> ephemeron gets sent finalize when the file is only referenced from
> ephemeris, and then the ephemeron can finalize the file itself, flushing
> any buffered characters and closing the file's descriptor. What we have
> now is a copy of the file in a weak registry, which means we finalize
> the copy not the actual file. This limits our ability to write clean
> file implementations. The same applies to several other uses of weak
> registries. Again Pharo is using the facility (and hence we can use
> their finalization process and some of their code).
>
> So the question is should we hold up the release for these features or
> should we go ahead and somehow arrange that we do address these (and
> other?) issues promptly in a subsequent release?
>
> Let me make a proposal. We go ahead and make a release with what we
> have, calling it Squeak 5.5, and then follow a plan to provide read-only
> object support, read-only literals, and as mush of the
> finalizationsystem rewritten to use ephemeron (where appropriate) as we
> can manage by, say, September 1. This will be Squeak 6. And the trunk
> process would update to requiring a rad-only-object enabled VM
> immediately after the 5.5 release.
>
> _,,,^..^,,,_
> best, Eliot
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

David T. Lewis
In reply to this post by Edgar De Cleene
On Fri, Mar 02, 2018 at 05:39:32AM -0300, Edgar J. De Cleene wrote:

> On 01/03/2018, 23:17, "David T. Lewis" <[hidden email]> wrote:
>
> > For that we should
> identify a person to serve as release manager to make it
> > happen. I expect
> we will discuss this in our board meeting next week, but
> > input (and volunteers
> or nominations) from anyone in the community would
> > certainly be welcome
>
> I'm could be that person.
>
> Edgar
> @morplenauta
>

Cool! Thanks Edgar :-)

To be honest the board has not paid enough attention to planning an
upcoming release, so I think it's going to be on the top of our agenda
this week.

Thanks a lot for volunteering, I have always admired the work that you
do with FunSqueak.

Dave


cbc
Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

cbc


On Fri, Mar 2, 2018 at 4:57 AM, David T. Lewis <[hidden email]> wrote:
On Fri, Mar 02, 2018 at 05:39:32AM -0300, Edgar J. De Cleene wrote:
> On 01/03/2018, 23:17, "David T. Lewis" <[hidden email]> wrote:
>
> > For that we should
> identify a person to serve as release manager to make it
> > happen. I expect
> we will discuss this in our board meeting next week, but
> > input (and volunteers
> or nominations) from anyone in the community would
> > certainly be welcome
>
> I'm could be that person.
>
> Edgar
> @morplenauta
>

Cool! Thanks Edgar :-)

To be honest the board has not paid enough attention to planning an
upcoming release, so I think it's going to be on the top of our agenda
this week.

Thanks a lot for volunteering, I have always admired the work that you
do with FunSqueak.
Hear Hear! Definitely.
-cbc

Dave





Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

K K Subbu
In reply to this post by fniephaus
On Friday 02 March 2018 05:43 PM, Fabio Niephaus wrote:

> Hi all,
>
> On Fri, Mar 2, 2018 at 11:30 AM K K Subbu <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Is there a plan to spin out Squeak (the ST VM) from Squeak (the image)
>     in this (or subsequent) release cycle? or will the two releases go
>     hand-in-hand forever?
>
>
> I always thought it was clear that with OpenSmalltalk release, I meant
> the VMs and not a new Squeak release. But it looks like people thought I
> was talking about a new Squeak release, thus Eliot's email I guess.
> Sorry for the confusion, my bad!

The message was posted to squeak-dev, so I assumed it was about Squeak
(the image). However, the Squeak VM is not really independent of Squeak
(the image) today. Part of VM is written in Slang and translated by
Squeak. My question was really about the plans to delink VM release from
the image release cycle. When a new Squeak image is released, will it
replace the reference image used to build the VM?

With the VM code moving to git and use of CI to automate patch, build
and test cycles, a full Squeak image may be an overkill. If
OpenSmalltalk is factored out to a separate release cycle, then only a
tiny Squeak image will be required to configure and translate Slang to C.

Should this thread continue in vm-dev instead?

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

David T. Lewis
In reply to this post by fniephaus
On Fri, Mar 02, 2018 at 12:13:01PM +0000, Fabio Niephaus wrote:

> Hi all,
>
> On Fri, Mar 2, 2018 at 11:30 AM K K Subbu <[hidden email]> wrote:
>
> > Is there a plan to spin out Squeak (the ST VM) from Squeak (the image)
> > in this (or subsequent) release cycle? or will the two releases go
> > hand-in-hand forever?
> >
>
> I always thought it was clear that with OpenSmalltalk release, I meant the
> VMs and not a new Squeak release. But it looks like people thought I was
> talking about a new Squeak release, thus Eliot's email I guess. Sorry for
> the confusion, my bad!

Don't apologize, your messages and requests to test candidate OpenSmalltalk
release candidates have been clear.

> I do agree that there should be a new Squeak release rather sooner than
> later, but I am still interested in having a new checkpoint for the VMs
> soon. This helps us to find out how stable current Squeak VMs are and it's
> also useful for things like CI.
>

Yes this makes sense, and there is no reason that release checkpoints for
the VMs should be directly tied to the release schedules for Squeak, Pharo,
or Cuis or other images. And yes, having periodic checkpoints for the VM
is a good thing. Your efforts here are appreciated.
 

>
> >
> > Now that the same VM is used by multiple (image) projects like Scratch,
> > Etoys, Pharo, Cuis and with binary variants like 32bit/64bit, cog/spur
> > etc. putting the VM on a separate cycle may be easier than linking it
> > with Squeak project releases. The VM may continue ship with a built-in
> > image for bootstrapping other images or for VMMaker but that need not be
> > linked with the latest Squeak release.
> >
>
> Those are some reasons why I think it would make sense to decouple the
> release processes for both the vm and the image. Why couple a new vm
> release to a Squeak or Pharo release if we could independently make new vm
> releases and then dialects can use the version they want or need. Maybe,
> this way we can fix VMs bugs without having to prepare a new image release:
> treat image and vm versions independently and only say "Squeak-5.x" needs
> "OpenSmalltalkVM Y or later" (assuming Squeak releases happen before
> breaking vm changes, such as Spur support).
>

+1000

Dave


> Best,
> Fabio
>
>
> >
> > Regards .. Subbu
> >
> > On Thursday 01 March 2018 11:27 PM, Eliot Miranda wrote:
> > > Hi All,
> > >
> > >      we're moving close to a new Squeak release.  There are some issues
> > > to discuss before we decide  exactly what and when to release.  I have
> > > two issues that I would like people's opinions on.
> > >
> > > 1. the VM can be compiled with support for read-only objects, and indeed
> > > Pharo is already doing this.  Were we to enable read-only object support
> > > we could introduce read-only bindings.  I have this code ready to go,
> > > but the current Squeak VM does not include read-only object support.  We
> > > could go ahead and release without read-only object support or enable
> > > read-only object support in the VM, push the new VMs out and enable
> > > read-only literals.  It would then take a few days for everyone to test
> > > their code and fix issues with read-only literals.  For example, code
> > > such as
> > >
> > > a := { 'one ' . 'two ' . 'three ' }.
> > > a do: [:e | e at: e size put: (Character value: 0)].
> > >
> > > must be rewritten, e.g. as
> > >
> > > a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll:
> > > Character space asString with: Character null asString].
> > >
> > > and the classic
> > >
> > > '' writeStream
> > >
> > > as
> > >
> > > '' copy writeStream
> > >
> > > i.e. literals are read-only but copies of literals are not.
> > >
> > > 2. the current VM, Monticello and the ClassBuilder has full support for
> > > ephemerons, which provide instance based finalization. For example, if a
> > > file that is the key of some ephemeron in a registration dictionary,
> > > then, with a suitable finalization process, the VM will arrange that the
> > > ephemeron gets sent finalize when the file is only referenced from
> > > ephemeris, and then the ephemeron can finalize the file itself, flushing
> > > any buffered characters and closing the file's descriptor. What we have
> > > now is a copy of the file in a weak registry, which means we finalize
> > > the copy not the actual file. This limits our ability to write clean
> > > file implementations. The same applies to several other uses of weak
> > > registries. Again Pharo is using the facility (and hence we can use
> > > their finalization process and some of their code).
> > >
> > > So the question is should we hold up the release for these features or
> > > should we go ahead and somehow arrange that we do address these (and
> > > other?) issues promptly in a subsequent release?
> > >
> > > Let me make a proposal. We go ahead and make a release with what we
> > > have, calling it Squeak 5.5, and then follow a plan to provide read-only
> > > object support, read-only literals, and as mush of the
> > > finalizationsystem rewritten to use ephemeron (where appropriate) as we
> > > can manage by, say, September 1. This will be Squeak 6. And the trunk
> > > process would update to requiring a rad-only-object enabled VM
> > > immediately after the 5.5 release.
> > >
> > > _,,,^..^,,,_
> > > best, Eliot
> > >
> > >
> > >
> >
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Edgar De Cleene
In reply to this post by David T. Lewis
The las FunSqueak was here
http://squeakros.org/FunSqueak4.6/ScreenSnapz.jpg
http://squeakros.org/FunSqueak4.6/FunSqueak4dot.6.zip

Aditional Alice stuff here
http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf
http://squeakros.org/FunSqueak4.6/SqueakObjects.zip

When/if Board says working in a release
5.2
5.5
6.0
I start to work , redoing FunSqueak4.6
And with the release .image made all test inside and think made FunSqueak
X.y let's know what need polish

Week reports to here for all know what's going on
And here https://discord.gg/aVeXVkC for live chat in Spanish or English


On 02/03/2018, 09:57, "David T. Lewis" <[hidden email]> wrote:

> Cool! Thanks Edgar :-)

To be honest the board has not paid enough attention
> to planning an
upcoming release, so I think it's going to be on the top of our
> agenda
this week.

Thanks a lot for volunteering, I have always admired the
> work that you
do with FunSqueak.

Dave




Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Edgar De Cleene
In reply to this post by K K Subbu
I like to know this tiny Squeak image


On 02/03/2018, 12:35, "K K Subbu" <[hidden email]> wrote:

> With the VM code moving to git and use of CI to automate patch, build
and
> test cycles, a full Squeak image may be an overkill. If
OpenSmalltalk is
> factored out to a separate release cycle, then only a
tiny Squeak image will
> be required to configure and translate Slang to C.




Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Stéphane Rollandin
In reply to this post by Edgar De Cleene
> Aditional Alice stuff here
> http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf
> http://squeakros.org/FunSqueak4.6/SqueakObjects.zip

Is there somewhere a cog VM for windows with 3D support?

Stef


Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Eliot Miranda-2


On Mar 3, 2018, at 12:41 PM, Stéphane Rollandin <[hidden email]> wrote:

>> Aditional Alice stuff here
>> http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf
>> http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
>
> Is there somewhere a cog VM for windows with 3D support?

Do the current bintray VMs not work?

>
> Stef
>
>

Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Nikolay Suslov
In reply to this post by Stéphane Rollandin
On Sat, Mar 3, 2018 at 11:41 PM, Stéphane Rollandin <[hidden email]> wrote:
Aditional Alice stuff here
http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf
http://squeakros.org/FunSqueak4.6/SqueakObjects.zip

Is there somewhere a cog VM for windows with 3D support?


Thinking, you need to check the Squeak.ini for B3DXUsesOpenGL=1

Regards,
Nikolai
 

Stef





Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Stéphane Rollandin
>         Aditional Alice stuff here
>         http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf
>         <http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf>
>         http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
>         <http://squeakros.org/FunSqueak4.6/SqueakObjects.zip>
>
>
>     Is there somewhere a cog VM for windows with 3D support?
>
>
>
> Thinking, you need to check the Squeak.ini for B3DXUsesOpenGL=1

Thanks. It appears it is the case.

More details:

I have been using Cog VM 45 (release) from March 10, 2016 to open the
FunSqueak4dot6 image provided by Edgar.

There I did 'Wonderland new' in a workspace, and got the warning message:

"This Squeak does not have read 3D support. Opening a Wonderland will be
EXTREMELY time consuming"

Tracing back the origin of this message, I saw that 'B3DPrimitiveEngine
isAvailable' returns false (because in turn B3DPrimitiveRasterizer,
B3DPrimitiveShader and B3DPrimitiveTransformer are not available) hence
my question.

Following your suggestion, I did checked that indeed B3DXUsesOpenGL=1 in
the Squeak.ini


best,

Stef

Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Stéphane Rollandin
In reply to this post by Eliot Miranda-2
>>> Aditional Alice stuff here
>>> http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf
>>> http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
>>
>> Is there somewhere a cog VM for windows with 3D support?
>
> Do the current bintray VMs not work?

I'm a bit lost wrt the VM flavors. Which one is the current bintray?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Hannes Hirzel
http://squeak.org/downloads/

should lead you to the correct place.

Under the heading 'Virtual machines' there is a link

https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files

If this is not helpful it needs to be updated ......

--Hannes

On 3/4/18, Stéphane Rollandin <[hidden email]> wrote:

>>>> Aditional Alice stuff here
>>>> http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf
>>>> http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
>>>
>>> Is there somewhere a cog VM for windows with 3D support?
>>
>> Do the current bintray VMs not work?
>
> I'm a bit lost wrt the VM flavors. Which one is the current bintray?
>
> Stef
>
>

Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Stéphane Rollandin
Le 04/03/2018 à 11:44, H. Hirzel a écrit :
> http://squeak.org/downloads/
>
> should lead you to the correct place.
>
> Under the heading 'Virtual machines' there is a link
>
> https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files

Ok, then I assume the current one for a 4.6 image is
cog_win32x86_squeak.cog.v3_201608171728

I tried it and got the same error, some 3D primitives are missing (see
my post in anwer to Nikolay).


Stef

Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Bob Arning-2

I can't even get that far. How did you get from the link mentioned before to the file you think might be the correct one?


On 3/4/18 6:03 AM, Stéphane Rollandin wrote:
Le 04/03/2018 à 11:44, H. Hirzel a écrit :
http://squeak.org/downloads/

should lead you to the correct place.

Under the heading 'Virtual machines' there is a link

https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files

Ok, then I assume the current one for a 4.6 image is cog_win32x86_squeak.cog.v3_201608171728

I tried it and got the same error, some 3D primitives are missing (see my post in anwer to Nikolay).


Stef




Reply | Threaded
Open this post in threaded view
|

Re: A new Squeak release

Stéphane Rollandin
> I can't even get that far. How did you get from the link mentioned
> before to the file you think might be the correct one?
>
>
> On 3/4/18 6:03 AM, Stéphane Rollandin wrote:
>> Le 04/03/2018 à 11:44, H. Hirzel a écrit :
>>> http://squeak.org/downloads/
>>>
>>> should lead you to the correct place.
>>>
>>> Under the heading 'Virtual machines' there is a link
>>>
>>> https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files
>>
>> Ok, then I assume the current one for a 4.6 image is
>> cog_win32x86_squeak.cog.v3_201608171728

I used the first link...

now from the second I just found squeak.cog.v3_win32x86_201803032041
which is more recent, but still with the same outcome: 3D primitives are
missing.

Stef

12