Smalltalk › Squeak › Squeak - Dev

replacing getSystemAttribute:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Nicolas Cellier

replacing getSystemAttribute:

I did propose and publish:
- vmPath for (getSystemAttribute: 0)
- imagePath for (getSystemAttribute: 1)
- documentPath for (getSystemAttribute: 2)

Unfortunately, I broke things because the first too were already
defined with a diferent semantic: return only the directory part, not
the full path (as I would have understood).
I stepped back, but still must fix #testWinVM3ButtonMousePreference.
I'd like to get your opinion. I propose:
- executableName
- imageArgument
- documentArgument

Anything better ?

Nicolas

keith1y

Re: replacing getSystemAttribute:

On 7 Mar 2010, at 16:09, Nicolas Cellier wrote:

I did propose and publish:
- vmPath for (getSystemAttribute: 0)
- imagePath for (getSystemAttribute: 1)
- documentPath for (getSystemAttribute: 2)

Unfortunately, I broke things because the first too were already
defined with a diferent semantic: return only the directory part, not
the full path (as I would have understood).
I stepped back, but still must fix #testWinVM3ButtonMousePreference.
I'd like to get your opinion. I propose:
- executableName
- imageArgument
- documentArgument

Anything better ?

Nicolas

You dont need to do this, these are part of StartupManager's responsibility.

Keith

Nicolas Cellier

Re: replacing getSystemAttribute:

2010/3/7 keith <[hidden email]>:

>
> On 7 Mar 2010, at 16:09, Nicolas Cellier wrote:
>
> I did propose and publish:
> - vmPath for (getSystemAttribute: 0)
> - imagePath for (getSystemAttribute: 1)
> - documentPath for (getSystemAttribute: 2)
>
> Unfortunately, I broke things because the first too were already
> defined with a diferent semantic: return only the directory part, not
> the full path (as I would have understood).
> I stepped back, but still must fix #testWinVM3ButtonMousePreference.
> I'd like to get your opinion. I propose:
> - executableName
> - imageArgument
> - documentArgument
>
> Anything better ?
>
> Nicolas
>
> You dont need to do this, these are part of StartupManager's
> responsibility.
> Keith
>
>

Hi Keith,

By now, I want message getSystemAttribute: to get private because the
argument is cryptic, and implementation dependent.
We don't have to program with encoded numbers, but should rather use
verbs and noun, the Smalltalk way.
Otherwise, I would just say (aStream nextPut: 13) instead of (aStream
cr), (paragraph alignment: 2) instead of (paragraph alignment:
Justified).
The encoding of arguments shall still exist, but only at two places at most:
- 1 in the VM
- 1 in the image

Concerning the class where the access methods should be implemented,
one thing emerged from recent discussion: it shall better be
accessible thru the object representing the system - Smalltalk
- either directly,
- or indirectly, via a message indirection (Smalltalk commandLine for example).
Maybe StartupManager is just a client for the commandLine information,
or it's the natural implementor of these messages as the main consumer
(the only one?).
That's an implementation detail we can discuss.
Or do you mean there should not be any other client ?

Nicolas

Bert Freudenberg

Re: replacing getSystemAttribute:

On 07.03.2010, at 17:43, Nicolas Cellier wrote:
>
> I want message getSystemAttribute: to get private because the
> argument is cryptic, and implementation dependent.

While I agree that it's better to use the symbolic accessors, the system attributes are precisely defined and should not be "implementation dependent".

- Bert -

keith1y

Re: replacing getSystemAttribute:

In reply to this post by Nicolas Cellier

Hi Keith,

By now, I want message getSystemAttribute: to get private because the
argument is cryptic, and implementation dependent.

I agree.

We don't have to program with encoded numbers, but should rather use
verbs and noun, the Smalltalk way.
Otherwise, I would just say (aStream nextPut: 13) instead of (aStream
cr), (paragraph alignment: 2) instead of (paragraph alignment:
Justified).
The encoding of arguments shall still exist, but only at two places at most:
- 1 in the VM
- 1 in the image

Concerning the class where the access methods should be implemented,
one thing emerged from recent discussion: it shall better be
accessible thru the object representing the system - Smalltalk
- either directly,
- or indirectly, via a message indirection (Smalltalk commandLine for example).

Exactly.

Maybe StartupManager is just a client for the commandLine information,
or it's the natural implementor of these messages as the main consumer
(the only one?).

It is the natural implementer.

That's an implementation detail we can discuss.
Or do you mean there should not be any other client ?

Nicolas

Simply put I am inviting you to contribute your ideas to the implementation of StartupManager, rather than start some competing implementation, which will then undermine the effort I put into StartupManger.

how about it?

Keith

Nicolas Cellier

Re: replacing getSystemAttribute:

In reply to this post by Bert Freudenberg

2010/3/7 Bert Freudenberg <[hidden email]>:
> On 07.03.2010, at 17:43, Nicolas Cellier wrote:
>>
>> I want message getSystemAttribute: to get private because the
>> argument is cryptic, and implementation dependent.
>
> While I agree that it's better to use the symbolic accessors, the system attributes are precisely defined and should not be "implementation dependent".
>
> - Bert -
>

Sure.
It works as long as new attribution are coordinated.
Now imagine Pharo goes with it's own VM...

By now, you can see machine specific usage of attributes 1200, 1201.
I find it hard to understand, and not commented. It's does not adhere
original Smalltalk spirit.

Nicolas

Nicolas Cellier

Re: replacing getSystemAttribute:

In reply to this post by keith1y

2010/3/7 keith <[hidden email]>:

>
>
> Hi Keith,
>
> By now, I want message getSystemAttribute: to get private because the
> argument is cryptic, and implementation dependent.
>
> I agree.
>
> We don't have to program with encoded numbers, but should rather use
> verbs and noun, the Smalltalk way.
> Otherwise, I would just say (aStream nextPut: 13) instead of (aStream
> cr), (paragraph alignment: 2) instead of (paragraph alignment:
> Justified).
> The encoding of arguments shall still exist, but only at two places at most:
> - 1 in the VM
> - 1 in the image
>
> Concerning the class where the access methods should be implemented,
> one thing emerged from recent discussion: it shall better be
> accessible thru the object representing the system - Smalltalk
> - either directly,
> - or indirectly, via a message indirection (Smalltalk commandLine for
> example).
>
> Exactly.
>
> Maybe StartupManager is just a client for the commandLine information,
> or it's the natural implementor of these messages as the main consumer
> (the only one?).
>
> It is the natural implementer.
>
> That's an implementation detail we can discuss.
> Or do you mean there should not be any other client ?
>
> Nicolas
>
> Simply put I am inviting you to contribute your ideas to the implementation
> of StartupManager, rather than start some competing implementation, which
> will then undermine the effort I put into StartupManger.
> how about it?
> Keith
>
>

It would be good to have a bit of cross fork coordination for the
basic system features.
Do you have a MC source or changeSet available ?

Nicolas

Bert Freudenberg

Re: replacing getSystemAttribute:

In reply to this post by Nicolas Cellier

On 07.03.2010, at 18:36, Nicolas Cellier wrote:

>
> 2010/3/7 Bert Freudenberg <[hidden email]>:
>> On 07.03.2010, at 17:43, Nicolas Cellier wrote:
>>>
>>> I want message getSystemAttribute: to get private because the
>>> argument is cryptic, and implementation dependent.
>>
>> While I agree that it's better to use the symbolic accessors, the system attributes are precisely defined and should not be "implementation dependent".
>>
>> - Bert -
>>
>
> Sure.
> It works as long as new attribution are coordinated.
> Now imagine Pharo goes with it's own VM...

I'd very much hope there is no need for that.

> By now, you can see machine specific usage of attributes 1200, 1201.
> I find it hard to understand, and not commented. It's does not adhere
> original Smalltalk spirit.

Sounds like a hack. What is it?

- Bert -

Nicolas Cellier

Re: replacing getSystemAttribute:

2010/3/7 Bert Freudenberg <[hidden email]>:

> On 07.03.2010, at 18:36, Nicolas Cellier wrote:
>>
>> 2010/3/7 Bert Freudenberg <[hidden email]>:
>>> On 07.03.2010, at 17:43, Nicolas Cellier wrote:
>>>>
>>>> I want message getSystemAttribute: to get private because the
>>>> argument is cryptic, and implementation dependent.
>>>
>>> While I agree that it's better to use the symbolic accessors, the system attributes are precisely defined and should not be "implementation dependent".
>>>
>>> - Bert -
>>>
>>
>> Sure.
>> It works as long as new attribution are coordinated.
>> Now imagine Pharo goes with it's own VM...
>
> I'd very much hope there is no need for that.
>
>> By now, you can see machine specific usage of attributes 1200, 1201.
>> I find it hard to understand, and not commented. It's does not adhere
>> original Smalltalk spirit.
>
> Sounds like a hack. What is it?
>
> - Bert -
>

Machine specific
1200 itsyVoltage (well commentged)
1201 code for recognition of HFS Plus onMac... (isActiveDirectoryClass)

Nicolas

keith1y

Re: replacing getSystemAttribute:

In reply to this post by Nicolas Cellier

Simply put I am inviting you to contribute your ideas to the implementation
of StartupManager, rather than start some competing implementation, which
will then undermine the effort I put into StartupManger.
how about it?
Keith

It would be good to have a bit of cross fork coordination for the
basic system features.
Do you have a MC source or changeSet available ?

"It would be good"... I disagree, I would say it is essential.

Code is available in:

https://code.launchpad.net/~keithy/cuis/System-Support_StartupManager

If you check it our you will find a cross fork changesets for each slice of functionality, and a cuis-integration changeset.

To work with these changesets in all forks of squeak, I recommend you take a look at

http://smalltalkers.pbworks.com/Getting-Started

regards

Keith