The Trunk: Collections-edc.314.mcz

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

The Trunk: Collections-edc.314.mcz

commits-2
Edgar J. De Cleene uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-edc.314.mcz

==================== Summary ====================

Name: Collections-edc.314
Author: edc
Time: 24 February 2010, 7:46:05.588 am
UUID: 74aa25e4-9646-4f83-9141-e72890b6cd4e
Ancestors: Collections-ul.313

Added String-lastPositionOf convenience method

=============== Diff against Collections-ul.313 ===============

Item was added:
+ ----- Method: String>>lastPositionOf: (in category 'testing') -----
+ lastPositionOf: aChar
+ "Answer the character position of the final space or other separator character in the receiver, and 0 if none"
+ self size to: 1 by: -1 do:
+ [:i | ((self at: i)= aChar) ifTrue: [^ i]].
+ ^ 0
+
+ "
+ 'fred the bear' lastSpacePosition
+ 'ziggie' lastSpacePosition
+ 'elvis ' lastSpacePosition
+ 'wimpy  ' lastSpacePosition
+ '' lastSpacePosition
+ "!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-edc.314.mcz

Bert Freudenberg
Huh? What's wrong with #lastIndexOf:?

- Bert -

On 24.02.2010, at 10:41, [hidden email] wrote:

>
> Edgar J. De Cleene uploaded a new version of Collections to project The Trunk:
> http://source.squeak.org/trunk/Collections-edc.314.mcz
>
> ==================== Summary ====================
>
> Name: Collections-edc.314
> Author: edc
> Time: 24 February 2010, 7:46:05.588 am
> UUID: 74aa25e4-9646-4f83-9141-e72890b6cd4e
> Ancestors: Collections-ul.313
>
> Added String-lastPositionOf convenience method
>
> =============== Diff against Collections-ul.313 ===============
>
> Item was added:
> + ----- Method: String>>lastPositionOf: (in category 'testing') -----
> + lastPositionOf: aChar
> + "Answer the character position of the final space or other separator character in the receiver, and 0 if none"
> + self size to: 1 by: -1 do:
> + [:i | ((self at: i)= aChar) ifTrue: [^ i]].
> + ^ 0
> +
> + "
> + 'fred the bear' lastSpacePosition
> + 'ziggie' lastSpacePosition
> + 'elvis ' lastSpacePosition
> + 'wimpy  ' lastSpacePosition
> + '' lastSpacePosition
> + "!
>
>




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-edc.314.mcz

Edgar J. De Cleene



On 2/24/10 8:47 AM, "Bert Freudenberg" <[hidden email]> wrote:

> Huh? What's wrong with #lastIndexOf:?
>
> - Bert -
Nothing
Sure I don't know when need and reinvent the wheel

Just I wish you have the same critic with all going to trunk...

Fell free to rip and change lastPositionOf: for lastIndexOf: so all happy

The point is you now could do

|loader |
    loader _ CodeLoader new.
    loader baseURL: 'http://www.squeaksource.com/Ladrillos/'.
    loader loadSourceFiles: #('Scamper-edc.13.mcz' );installSourceFiles.

Or many of examples coming from

http://wiki.squeak.org/squeak/6056

Edgar




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-edc.314.mcz

Levente Uzonyi-2
On Wed, 24 Feb 2010, Edgar J. De Cleene wrote:

>
>
>
> On 2/24/10 8:47 AM, "Bert Freudenberg" <[hidden email]> wrote:
>
>> Huh? What's wrong with #lastIndexOf:?
>>
>> - Bert -
> Nothing
> Sure I don't know when need and reinvent the wheel
>
> Just I wish you have the same critic with all going to trunk...
>

I doubt that other code gets less critic.
If you're unsure that your code is generally useful or it may break some
stuff, just upload it to the Inbox and write a mail here about the
changes your code does. You can even add an Installer script to your mail,
so others can load the packages easily.

> Fell free to rip and change lastPositionOf: for lastIndexOf: so all happy
>
> The point is you now could do
>
> |loader |
>    loader _ CodeLoader new.
>    loader baseURL: 'http://www.squeaksource.com/Ladrillos/'.
>    loader loadSourceFiles: #('Scamper-edc.13.mcz' );installSourceFiles.
>
> Or many of examples coming from
>
> http://wiki.squeak.org/squeak/6056

Installer is a better tool to load these IMHO.


Levente

>
> Edgar
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-edc.314.mcz

Edgar J. De Cleene



On 2/24/10 1:10 PM, "Levente Uzonyi" <[hidden email]> wrote:

> I doubt that other code gets less critic.
> If you're unsure that your code is generally useful or it may break some
> stuff, just upload it to the Inbox and write a mail here about the
> changes your code does. You can even add an Installer script to your mail,
> so others can load the packages easily.
I send ,no feedback

> Installer is a better tool to load these IMHO.
>
>
> Levente


But Installer  and all the others loader should be unloaded with Smalltalk
unloadAllKnownPackages.

Smalltalk unloadAllKnownPackages. Should be the first we do for having the
next .image (SL3, 4.1, Mendieta)


You could load Installer if suits best your needs.

I insist CodeLoader is useful and more clear as you put the repositories and
exact versions.

Edgar




Reply | Threaded
Open this post in threaded view
|

Installer vs. CodeLoader (was: The Trunk: Collections-edc.314.mcz)

Bert Freudenberg
On 25.02.2010, at 10:52, Edgar J. De Cleene wrote:

>
>
>
>
> On 2/24/10 1:10 PM, "Levente Uzonyi" <[hidden email]> wrote:
>
>> I doubt that other code gets less critic.
>> If you're unsure that your code is generally useful or it may break some
>> stuff, just upload it to the Inbox and write a mail here about the
>> changes your code does. You can even add an Installer script to your mail,
>> so others can load the packages easily.
> I send ,no feedback
>
>> Installer is a better tool to load these IMHO.
>>
>>
>> Levente
>
>
> But Installer  and all the others loader should be unloaded with Smalltalk
> unloadAllKnownPackages.
>
> Smalltalk unloadAllKnownPackages. Should be the first we do for having the
> next .image (SL3, 4.1, Mendieta)

I'd think that any non-core image should have Installer. And a core image should not have CodeLoader either.

> You could load Installer if suits best your needs.
>
> I insist CodeLoader is useful and more clear as you put the repositories and
> exact versions.

But you are aware that CodeLoader was created for a very different purpose, right? It's not supposed to load code for development. It's used to load code at runtime in user applications. Signature verification and security sandboxing is one of the major responsibilities of CodeLoader, as is fetching the code from remote sources.

Installer gained a lot of support lately. It's what we commonly use for loading development stuff now. Why would you insist on differing? In Installer you can give exact repositories and versions, too.

I'd rather remove your CodeLoader extensions. If others wanted them to stay, then we would at least have to change it to not bypass the security checks.

Levente already stated he preferred Installer. So with me that's 2:1 against extending CodeLoader. Any other opinions either way?

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Collections-edc.314.mcz

Igor Stasenko
In reply to this post by Edgar J. De Cleene
On 25 February 2010 11:52, Edgar J. De Cleene <[hidden email]> wrote:

>
>
>
> On 2/24/10 1:10 PM, "Levente Uzonyi" <[hidden email]> wrote:
>
>> I doubt that other code gets less critic.
>> If you're unsure that your code is generally useful or it may break some
>> stuff, just upload it to the Inbox and write a mail here about the
>> changes your code does. You can even add an Installer script to your mail,
>> so others can load the packages easily.
> I send ,no feedback
>
>> Installer is a better tool to load these IMHO.
>>
>>
>> Levente
>
>
> But Installer  and all the others loader should be unloaded with Smalltalk
> unloadAllKnownPackages.
>
> Smalltalk unloadAllKnownPackages. Should be the first we do for having the
> next .image (SL3, 4.1, Mendieta)
>
>
> You could load Installer if suits best your needs.
>
> I insist CodeLoader is useful and more clear as you put the repositories and
> exact versions.
>

This code

|loader |
  loader _ CodeLoader new.
  loader baseURL: 'http://www.squeaksource.com/Ladrillos/'.
  loader loadSourceFiles: #('Scamper-edc.13.mcz' );installSourceFiles.

doesn't works in my image
a collection, which it tries to read starts from
'PK
which is not a source file, but contents of a .zip file (which mcz is).


I don't know why you insist on not using Installer, but insist on
using CodeLoader,
which as to me is hugely inferior tool.

Why then not just use something like:

MczInstaller installStream:
'http://www.squeaksource.com/Ladrillos/Scamper-edc.13.mcz' asUrl
retrieveContents contentStream

and throw out useless (CodeLoader) stuff from image??

> Edgar
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Installer vs. CodeLoader (was: The Trunk: Collections-edc.314.mcz)

Igor Stasenko
In reply to this post by Bert Freudenberg
On 25 February 2010 13:24, Bert Freudenberg <[hidden email]> wrote:

> On 25.02.2010, at 10:52, Edgar J. De Cleene wrote:
>>
>>
>>
>>
>> On 2/24/10 1:10 PM, "Levente Uzonyi" <[hidden email]> wrote:
>>
>>> I doubt that other code gets less critic.
>>> If you're unsure that your code is generally useful or it may break some
>>> stuff, just upload it to the Inbox and write a mail here about the
>>> changes your code does. You can even add an Installer script to your mail,
>>> so others can load the packages easily.
>> I send ,no feedback
>>
>>> Installer is a better tool to load these IMHO.
>>>
>>>
>>> Levente
>>
>>
>> But Installer  and all the others loader should be unloaded with Smalltalk
>> unloadAllKnownPackages.
>>
>> Smalltalk unloadAllKnownPackages. Should be the first we do for having the
>> next .image (SL3, 4.1, Mendieta)
>
> I'd think that any non-core image should have Installer. And a core image should not have CodeLoader either.
>
>> You could load Installer if suits best your needs.
>>
>> I insist CodeLoader is useful and more clear as you put the repositories and
>> exact versions.
>
> But you are aware that CodeLoader was created for a very different purpose, right? It's not supposed to load code for development. It's used to load code at runtime in user applications. Signature verification and security sandboxing is one of the major responsibilities of CodeLoader, as is fetching the code from remote sources.
>
> Installer gained a lot of support lately. It's what we commonly use for loading development stuff now. Why would you insist on differing? In Installer you can give exact repositories and versions, too.
>
> I'd rather remove your CodeLoader extensions. If others wanted them to stay, then we would at least have to change it to not bypass the security checks.
>
> Levente already stated he preferred Installer. So with me that's 2:1 against extending CodeLoader. Any other opinions either way?
>
Me.
3:1

Dragging the tool from a dusty shelf, which not actually fits the
purpose is a bad move as to me.

> - Bert -
>

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Installer vs. CodeLoader

Andreas.Raab
In reply to this post by Bert Freudenberg
Bert Freudenberg wrote:
> Levente already stated he preferred Installer. So with me that's 2:1 against extending CodeLoader. Any other opinions either way?

+1 for Installer. The purpose of CodeLoader is to load code in an
application, thus signatures, verification etc. Let's use the right tool
for the right job - CodeLoader was specifically designed to support
(Etoys) projects in browsers, Installer specifically to load arbitrary
code from arbitrary places during development.

Cheers,
   - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Installer vs. CodeLoader

Bert Freudenberg
On 25.02.2010, at 14:32, Andreas Raab wrote:
>
> Bert Freudenberg wrote:
>> Levente already stated he preferred Installer. So with me that's 2:1 against extending CodeLoader. Any other opinions either way?
>
> +1 for Installer. The purpose of CodeLoader is to load code in an application, thus signatures, verification etc. Let's use the right tool for the right job - CodeLoader was specifically designed to support (Etoys) projects in browsers, Installer specifically to load arbitrary code from arbitrary places during development.
>
> Cheers,
>  - Andreas

Okay. I pushed System-bf.265 which backs out the additions.

Sorry Edgar - this is just about CodeLoader, not about your other, valuable contributions. Keep it up! :)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Installer vs. CodeLoader (was: The Trunk: Collections-edc.314.mcz)

keith1y
In reply to this post by Igor Stasenko
>> I'd think that any non-core image should have Installer. And a core  
>> image should not have CodeLoader either.
>>
>>> You could load Installer if suits best your needs.


I think it would help to clarify nomenclature (again)...

kernel
core
build
basic
developer / fun
web / full
max

The kernel image would be the image with an absolute minimum, except I  
would argue the ability to specify a single local script on the  
command line, &/ a REPL to the console. The kernel would not even be  
expected to have a UI, and it does not have to be usable, apart from  
running command line scripts, or something.

A core image is one that has a GUI, is usable, and has one dependency  
(i.e. Installer or equivalent) for loading anything else.
i.e. it should not have MC because MC is loadable easily with  
installer. If you do provide MC in the core then you potentially  
prevent others from loading different implementations of MC.

A build image is one that has a selection of tools for building bigger  
images, so might have one or more of SqueakMap, Universes, MC, Gofer  
Metacello etc.

A basic image would be the standard release. I.e. a selection of tools  
chosen and loaded out of the menu of available options. i.e. pick the  
Transcript implementation, Browsers etc.

Developer/web/seaside/magma derived images for different purposes,  
either based on "basic", with the standard tools, or "build" with non-
standard tools

full/fun - the old style everything interesting demo as we had with  
3.7-full

max - every package that can load loaded.

regards

Keith

Reply | Threaded
Open this post in threaded view
|

Re: Installer vs. CodeLoader (was: The Trunk: Collections-edc.314.mcz)

Ralph Johnson
These are excellent definitions.  Someone should put them on a web page so we can just cite them instead of repeating them.

Note that kernel < core < build < basic < developer < max  while basic < web < max and I suppose basic < fun < max

Note also that max might not load.  Also, we might eventually decide that if we have one, we don't need another.  For example, perhaps if we have core and some good scripts for building images, we don't need build.  But I bet that for each image, there will be somebody who will want it.

it seems to me like 4.0 is more like basic.  Is that true?  What will 4.1 be like?

On Thu, Feb 25, 2010 at 10:35 AM, keith <[hidden email]> wrote:

I think it would help to clarify nomenclature (again)...

kernel
core
build
basic
developer / fun
web / full
max

The kernel image would be the image with an absolute minimum, except I would argue the ability to specify a single local script on the command line, &/ a REPL to the console. The kernel would not even be expected to have a UI, and it does not have to be usable, apart from running command line scripts, or something.

A core image is one that has a GUI, is usable, and has one dependency (i.e. Installer or equivalent) for loading anything else.
i.e. it should not have MC because MC is loadable easily with installer. If you do provide MC in the core then you potentially prevent others from loading different implementations of MC.

A build image is one that has a selection of tools for building bigger images, so might have one or more of SqueakMap, Universes, MC, Gofer Metacello etc.

A basic image would be the standard release. I.e. a selection of tools chosen and loaded out of the menu of available options. i.e. pick the Transcript implementation, Browsers etc.

Developer/web/seaside/magma derived images for different purposes, either based on "basic", with the standard tools, or "build" with non-standard tools

full/fun - the old style everything interesting demo as we had with 3.7-full

max - every package that can load loaded.

regards

Keith




Reply | Threaded
Open this post in threaded view
|

Re: Installer vs. Code Loader (was: The Trunk: Collections-edc.314.mcz)

Edgar J. De Cleene
In reply to this post by keith1y



On 2/25/10 2:35 PM, "keith" <[hidden email]> wrote:

>>> I'd think that any non-core image should have Installer. And a core
>>> image should not have CodeLoader either.
>>>
>>>> You could load Installer if suits best your needs.
>
>
> I think it would help to clarify nomenclature (again)...
>
> kernel
> core
> build
> basic
> developer / fun
> web / full
> max
>
> The kernel image would be the image with an absolute minimum, except I
> would argue the ability to specify a single local script on the
> command line, &/ a REPL to the console. The kernel would not even be
> expected to have a UI, and it does not have to be usable, apart from
> running command line scripts, or something.

 
> A core image is one that has a GUI, is usable, and has one dependency
> (i.e. Installer or equivalent) for loading anything else.
> i.e. it should not have MC because MC is loadable easily with
> installer. If you do provide MC in the core then you potentially
> prevent others from loading different implementations of MC.

> A build image is one that has a selection of tools for building bigger
> images, so might have one or more of SqueakMap, Universes, MC, Gofer
> Metacello etc.
>
> A basic image would be the standard release. I.e. a selection of tools
> chosen and loaded out of the menu of available options. i.e. pick the
> Transcript implementation, Browsers etc.
>
> Developer/web/seaside/magma derived images for different purposes,
> either based on "basic", with the standard tools, or "build" with non-
> standard tools
>
> full/fun - the old style everything interesting demo as we had with
> 3.7-full
>
> max - every package that can load loaded.
>
> regards
>
> Keith

First time I agree with Keith in long time.

I see a pattern in the disagree of all other Masters.
And is a cultural , not a technical one.
Here in Argentina , people try to squish older things beyond his designed
use.

But I don wish hurt any.
If a small change to business as usual could have the cause the dead of
Squeak also I vote for revert CodeLoader.

And I send the code here, not guilty if nobody say is not good before I put
into repositories.

Stick myself to discover bugs.

Edgar








Reply | Threaded
Open this post in threaded view
|

Re: Installer vs. CodeLoader (was: The Trunk: Collections-edc.314.mcz)

Edgar J. De Cleene
In reply to this post by Ralph Johnson
Re: [squeak-dev] Installer vs. CodeLoader (was: The Trunk:  Collections-edc.314.mcz)


On 2/25/10 2:48 PM, "Ralph Johnson" <[hidden email]> wrote:

These are excellent definitions.  Someone should put them on a web page so we can just cite them instead of repeating them.

Note that kernel < core < build < basic < developer < max  while basic < web < max and I suppose basic < fun < max

Note also that max might not load.  Also, we might eventually decide that if we have one, we don't need another.  For example, perhaps if we have core and some good scripts for building images, we don't need build.  But I bet that for each image, there will be somebody who will want it.

it seems to me like 4.0 is more like basic.  Is that true?  What will 4.1 be like?


I wish be Sl3, with corrected code and new name.
See http://n4.nabble.com/ANN-SL3-11-9375-alpha-zip-td1555132.html

I delay this until we finish the current trunk phase.

Edgar