[Pharo-project] String asPacked/fromPacked:
Hi I discovered this protocol in String hierarchy. Are you familiar with it? The method comment of #fromPacked: is: "Convert from a longinteger to a String of length 4." The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work. In examples: ByteString fromPacked: 'text' asPacked. ---> 'text' ByteString fromPacked: 'martin' asPacked. ---> 'rtin' WideString fromPacked: ('text' asWideString asPacked). ---> error WideString>>asPacked can be easily fixed adding an explicit return to the calculation (it's now implicitly returning self). But... it only encodes one letter: WideString fromPacked: 'martin' asWideString asPacked ---> 'n' I checked that in Squeak 4.3 there are not senders too. So... Should we fix the WideString implementation, or directly remove this protocol? Martin
On Feb 27, 2013, at 11:19 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi
I discovered this protocol in String hierarchy. Are you familiar with it?
The method comment of #fromPacked: is: "Convert from a longinteger to a String of length 4."
The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work.
In examples:
ByteString fromPacked: 'text' asPacked. ---> 'text' ByteString fromPacked: 'martin' asPacked. ---> 'rtin' WideString fromPacked: ('text' asWideString asPacked). ---> error
WideString>>asPacked can be easily fixed adding an explicit return to the calculation (it's now implicitly returning self).
But... it only encodes one letter:
WideString fromPacked: 'martin' asWideString asPacked ---> 'n'
I checked that in Squeak 4.3 there are not senders too.
So... Should we fix the WideString implementation, or directly remove this protocol?
If something is only in the MethodFinder referenced it shows that it is very very old. (We really need to clean up the MethodFinder, it references a lot of crap). remove. Marcus
Marcus Denker-4 wrote
(We really need to clean up the MethodFinder, it references a lot of crap).
I changed Issue 7619 to "Cleanup MethodFinder". Would pragmas be useful here? -- View this message in context: http://forum.world.st/String-asPacked-fromPacked-tp4672413p4672687.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Feb 28, 2013, at 2:07 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Marcus Denker-4 wrote
(We really need to clean up the MethodFinder, it references a lot of crap).
I changed Issue 7619 to "Cleanup MethodFinder". Would pragmas be useful here?
I don't know. The small fix we can do immediately. Cleaning MethodFinder needs serious thought and work, so if that is the issue where will be no progress for a while. Let's clean the trivial thing *now* (that is, when 3.0 is started), and add a second issue for the MethodFinder. As for it: it uses positive tagging. "It is ok to run this method as there are no side effects". Do you want a pragma in *every* method? I don't. For things like this we need a way to associate meta data with methods that is a bit less intrusive, yet stored in a way that it is not lost⦠And maybe it should be part of MethodFinder, not part of the method itself. Marcus
On Feb 28, 2013, at 2:17 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 28, 2013, at 2:07 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Marcus Denker-4 wrote
(We really need to clean up the MethodFinder, it references a lot of crap).
I changed Issue 7619 to "Cleanup MethodFinder". Would pragmas be useful here?
I don't know. The small fix we can do immediately. Cleaning MethodFinder needs serious thought and work, so if that is the issue where will be no progress for a while.
Let's clean the trivial thing *now* (that is, when 3.0 is started), and add a second issue for the MethodFinder.
As for it: it uses positive tagging. "It is ok to run this method as there are no side effects". Do you want a pragma in *every* method? I don't.
For things like this we need a way to associate meta data with methods that is a bit less intrusive, yet stored in a way that it is not lost⦠And maybe it should be part of MethodFinder, not part of the method itself.
If possible it should abstract away from MethodFinder and encode something about side-effects⦠Or one could have some form of sandboxed secure environment to run stuff and it's not a problem if there are side effects. It's all not easy⦠doing MethodFinder right is very hard. Up to the point that the trivial thing there is now is the actually the sweet spot? Of course the code is horrible, absolutely horrible⦠I even removed it in the development phase of 1.0 once, because it is just ugly and referencing so many symbols⦠but it is a fun demo. Now how can one implement that fun demo "For real"? Having the info that a method can be called safely actually could be interesting for other things, e.g. random testing. http://code.google.com/p/yeti-test/ Marcus
If possible it should abstract away from MethodFinder and encode something about side-effectsâ¦
Or one could have some form of sandboxed secure environment to run stuff and it's not a problem if there are side effects.
It's all not easy⦠doing MethodFinder right is very hard. Up to the point that the trivial thing there is now is the actually the sweet spot?
Of course the code is horrible, absolutely horrible⦠I even removed it in the development phase of 1.0 once, because it is just ugly and referencing so many symbols⦠but it is a fun demo.
Method Finder is not a demo it is a really powerful tool. So we should invest in it Stef
Now how can one implement that fun demo "For real"?
Having the info that a method can be called safely actually could be interesting for other things, e.g. random testing. http://code.google.com/p/yeti-test/
Marcus
tinchodias wrote
Are you talking about an specific pragma for deprecation? I didn't catch it.
I was thinking of something like <safeForMethodFinder>, but agree with Marcus's objection that those would have to be sprinkled everywhere in the system. It solves one problem, but creates another... -- View this message in context: http://forum.world.st/String-asPacked-fromPacked-tp4672413p4672713.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Thank you Sean and Marcus. I tried to find all methods that are only referenced by MethodFinder (like asPacked), but I gave up after some minutes... Yeti sounds good. I remember a guy from Germany that come to Smalltalks 2009 (IIRC) that showed the testing tools from his company, made in smalltalk. It was a nice presentation. Martin On Thu, Feb 28, 2013 at 3:00 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
tinchodias wrote
Are you talking about an specific pragma for deprecation? I didn't catch it.
I was thinking of something like <safeForMethodFinder>, but agree with Marcus's objection that those would have to be sprinkled everywhere in the system. It solves one problem, but creates another...
-- View this message in context: http://forum.world.st/String-asPacked-fromPacked-tp4672413p4672713.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
In reply to the reference to #deprecation, removal is the only viable option in this case. The implementations of WideString >> #asPacked and WideString class >> #fromPacked: fundamentally disagree in what it means for a WideString to be packed, and there's no telling how long it's been that way. In other words; straight up remove it, and leave it up to whichever user may require it to provide a consistent implementation as per his/her usage. Cheers, Henry
On Feb 28, 2013, at 3:00 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
tinchodias wrote
Are you talking about an specific pragma for deprecation? I didn't catch it.
I was thinking of something like <safeForMethodFinder>, but agree with Marcus's objection that those would have to be sprinkled everywhere in the system. It solves one problem, but creates anotherâ¦
why? because this is only for important core methods so
On 27 Feb 2013, at 11:19, Martin Dias <tinchodias@gmail.com> wrote:
Hi
I discovered this protocol in String hierarchy. Are you familiar with it?
The method comment of #fromPacked: is: "Convert from a longinteger to a String of length 4."
The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work.
In examples:
ByteString fromPacked: 'text' asPacked. ---> 'text' ByteString fromPacked: 'martin' asPacked. ---> 'rtin' WideString fromPacked: ('text' asWideString asPacked). ---> error
WideString>>asPacked can be easily fixed adding an explicit return to the calculation (it's now implicitly returning self).
But... it only encodes one letter:
WideString fromPacked: 'martin' asWideString asPacked ---> 'n'
I checked that in Squeak 4.3 there are not senders too.
So... Should we fix the WideString implementation, or directly remove this protocol?
Martin
It might have something to do with pre Mac OS X days, Mac creator/type codes. Unless this follows some open standard with a spec, I would say nuke it. Doing something like this without specifying encoding strikes me as dangerous. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Ok, so I will open an issue to nuke it! 3.0 ? On Wed, Feb 27, 2013 at 11:26 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 27 Feb 2013, at 11:19, Martin Dias <tinchodias@gmail.com> wrote:
Hi
I discovered this protocol in String hierarchy. Are you familiar with it?
The method comment of #fromPacked: is: "Convert from a longinteger to a String of length 4."
The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work.
In examples:
ByteString fromPacked: 'text' asPacked. ---> 'text' ByteString fromPacked: 'martin' asPacked. ---> 'rtin' WideString fromPacked: ('text' asWideString asPacked). ---> error
WideString>>asPacked can be easily fixed adding an explicit return to the calculation (it's now implicitly returning self).
But... it only encodes one letter:
WideString fromPacked: 'martin' asWideString asPacked ---> 'n'
I checked that in Squeak 4.3 there are not senders too.
So... Should we fix the WideString implementation, or directly remove this protocol?
Martin
It might have something to do with pre Mac OS X days, Mac creator/type codes.
Unless this follows some open standard with a spec, I would say nuke it.
Doing something like this without specifying encoding strikes me as dangerous.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
One great things about Pharo is the ability to nuke old crap. It feels good :-) Phil 2013/2/27 Sven Van Caekenberghe <sven@stfx.eu>:
On 27 Feb 2013, at 11:19, Martin Dias <tinchodias@gmail.com> wrote:
Hi
I discovered this protocol in String hierarchy. Are you familiar with it?
The method comment of #fromPacked: is: "Convert from a longinteger to a String of length 4."
The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work.
In examples:
ByteString fromPacked: 'text' asPacked. ---> 'text' ByteString fromPacked: 'martin' asPacked. ---> 'rtin' WideString fromPacked: ('text' asWideString asPacked). ---> error
WideString>>asPacked can be easily fixed adding an explicit return to the calculation (it's now implicitly returning self).
But... it only encodes one letter:
WideString fromPacked: 'martin' asWideString asPacked ---> 'n'
I checked that in Squeak 4.3 there are not senders too.
So... Should we fix the WideString implementation, or directly remove this protocol?
Martin
It might have something to do with pre Mac OS X days, Mac creator/type codes.
Unless this follows some open standard with a spec, I would say nuke it.
Doing something like this without specifying encoding strikes me as dangerous.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
I reported it for 3.0 here: https://code.google.com/p/pharo/issues/detail?id=7619 Cheers, Martin On Wed, Feb 27, 2013 at 11:35 AM, phil@highoctane.be <phil@highoctane.be> wrote:
One great things about Pharo is the ability to nuke old crap.
It feels good :-)
Phil
2013/2/27 Sven Van Caekenberghe <sven@stfx.eu>:
On 27 Feb 2013, at 11:19, Martin Dias <tinchodias@gmail.com> wrote:
Hi
I discovered this protocol in String hierarchy. Are you familiar with it?
The method comment of #fromPacked: is: "Convert from a longinteger to a String of length 4."
The only sender in Pharo 2.0 is MethodFinder. For WideString, it does not work.
In examples:
ByteString fromPacked: 'text' asPacked. ---> 'text' ByteString fromPacked: 'martin' asPacked. ---> 'rtin' WideString fromPacked: ('text' asWideString asPacked). ---> error
WideString>>asPacked can be easily fixed adding an explicit return to the calculation (it's now implicitly returning self).
But... it only encodes one letter:
WideString fromPacked: 'martin' asWideString asPacked ---> 'n'
I checked that in Squeak 4.3 there are not senders too.
So... Should we fix the WideString implementation, or directly remove this protocol?
Martin
It might have something to do with pre Mac OS X days, Mac creator/type codes.
Unless this follows some open standard with a spec, I would say nuke it.
Doing something like this without specifying encoding strikes me as dangerous.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
participants (7)
-
Henrik Johansen -
Marcus Denker -
Martin Dias -
phil＠highoctane.be -
Sean P. DeNigris -
stephane ducasse -
Sven Van Caekenberghe