Pharo vs GLASS: Date format difference

Just found another little issue while trying to run MailMessage in GLASS.

The following method uses the ascii value 47.

date
    "Answer a date string for this message."

    ^(Date fromSeconds: self time + (Date newDay: 1 year: 1980) asSeconds)
        printFormat: #(2 1 3 47 1 2)


GLASS does not support ascii value in the Date format.

A trivial fix is to change MailMessage method using a Character.

date
    "Answer a date string for this message."

    ^(Date fromSeconds: self time + (Date newDay: 1 year: 1980) asSeconds)
        printFormat: #(2 1 3 $/ 1 2)


But is that the right way to fix it?  Should the GLASS side format method be changed to be supporting the same format as Pharo?



Thierry

Sorry for the ranting, but that's the first time I am attempting to port something from Pharo to GLASS.  I am just trying to understand how to balance the fixes for myself vs the community.


Here is another example:

Date today printFormat: #(2 1 3 $/ 1 2)

In Pharo: '4/7/11'
In GLASS: '04/07/11'.


Again, I can quickly fix that for my needs (right now I am just trying to pass some tests). But what should be the longer term strategy?



Thierry

A little discussion with myself ;-)

Looking at these portability issues, I think that I have few options:

1- Just make it work for my needs.  But that feels like 'brushing under the rug' and not helping the community. At minimum I could mention the issues on this list?
2- Whenever feasible, fix the issue in the package itself. For example MailMessage could as easily be using printFormat: #(2 1 3 $/ 1 2) instead of printFormat: #(2 1 3 47 1 2). I am not sure about the process to make such change back to the main repository. Another option would be branching? But having two branches (one for Pharo, one for GLASS) might be diffcult to maintain.
3- Change GLASS/GemStone code.  But then some GemStone/S users might not be happy with the changes...
4- Grease? 

Comments?

Thierry

On 04/07/2011 11:03 AM, Thierry Thelliez wrote:
Thierry,

Ultimately, I want GLASS to have 100% fidelity with Pharo, but that is
not the case at the moment ... the best strategy for you is to submit a
bug report for the discrepencies you find including your workaround and
I'll eventually incorporate the fix ... my typical approach is to
harvest the relevant unit tests from Pharo and run them in GLASS and
then fix the specific issue that was reported along with any that come
up during the "harvest" ...

For larger and more complex issues (where you don't have a clean/obvious
workaround) it may be worth integrating your fix into the GLASS
infrastructure and putting changes into either the Squeak or Pharo
compatibility packages (I'm moving away from putting all of the code in
the Squeak package since Squeak and Pharo are diverging), but then the
were's the why's and the how's should be discussed on the list ...

Da;e

Thierry,

Very good points ... more comments interspersed...

On 04/07/2011 11:17 AM, Thierry Thelliez wrote:
> A little discussion with myself ;-)
>
> Looking at these portability issues, I think that I have few options:
>
> 1- Just make it work for my needs.  But that feels like 'brushing under
> the rug' and not helping the community. At minimum I could mention the
> issues on this list?

I would say that the minimum is a bug report.

> 2- Whenever feasible, fix the issue in the package itself. For example
> MailMessage could as easily be using printFormat: #(2 1 3 $/ 1 2)
> instead of printFormat: #(2 1 3 *47* 1 2). I am not sure about the
> process to make such change back to the main repository. Another option
> would be branching? But having two branches (one for Pharo, one for
> GLASS) might be diffcult to maintain.

Agreed. If there is a portable solution, then that should be used,
nonetheless, since it is desirable for GLASS to be compatible, use the
portable solution and check change into main repository ..... submit an
issue so that we have a chance to be compatible with this pattern in the
future.

If you have commit rights then make the change in the package ...
GemStone-specific branches are appropriate when there is no common
solution and the other alternatives just don't work.

> 3- Change GLASS/GemStone code.  But then some GemStone/S users might not
> be happy with the changes...

I'm trying to control the code so that you can have pharo compatibility
or not ... there are a number of options for the future and it is slow
in coming, but develop in Pharo in deploy in GemStone is the top use
case ... I just don't want it to be the exclusive use case ...

> 4- Grease?

Since the goal for GLASS is compatibility, it shouldn't be a driving
factor for new Grease features/support ...

Dale