Smalltalk › Pharo › Pharo Smalltalk Users

Enhancing ICal library

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Julien Delplanque

Enhancing ICal library

Hi everyone,

I took a little time to enhance the ICal library and to make it work
with Pharo 4!

So I forked the one on smalltalkhub
(http://smalltalkhub.com/#!/~pdebruic/iCal) and put all the modified
code on github https://github.com/juliendelplanque/pharo-ical.

Why did I forked? Well, I wanted to make it work on pharo 4 first, so I
contacted the owner of the smalltalkhub repository. He wanted to keep it
working on other smalltalk than Pharo. The problem was that the lib used
Url class that were deprecated in Pharo 3 and even removed on Pharo 4!
So I managed to repair the package using ZnUrl. Since I don't know if
the owner of this lib on Smalltalkhub have time to manage the problem to
keep the lib "multi-smalltalk", I have chosen to fork it so he can keep
his version compatible.

Good news are that I plan to keep it alive as long as I can, write some
documentation for it when I have time and even try to enhance it.

I already added a GTInspector extension to have better representation
of iCalendar when inspecting them in Pharo.

The version on master branch is supported by Pharo 2-3-4 (didn't check
with Pharo 1).

Regards,

Julien

Damien Cassou-2

Re: Enhancing ICal library

Hi Julien,

Julien Delplanque <[hidden email]> writes:

> Hi everyone,
>
> I took a little time to enhance the ICal library and to make it work
> with Pharo 4!
>
> So I forked the one on smalltalkhub
> (http://smalltalkhub.com/#!/~pdebruic/iCal) and put all the modified
> code on github https://github.com/juliendelplanque/pharo-ical.

that's great news, thank you very much for this work. This kind of
library is very important. 2 suggestions:

- could you please create a Jenkins job at
https://ci.inria.fr/pharo-contribution/ to monitor the project?

- if you write your documentation in the next few weeks and in Pillar
(http://www.smalltalkhub.com/#!/~Pier/Pillar), we might include the
chapter in the next EnterprisePharo book (no promise, but iCal would
fit well in the book theme). If you are not fast enough, we could
still include it in one of the next books.

> I already added a GTInspector extension to have better representation
> of iCalendar when inspecting them in Pharo.

A calendar view would be awesome (but probably a lot of work too :-)).

A list of nicely-formatted events would already be great. Something
along the lines of
http://getandroidstuff.com/wp-content/uploads/2013/01/Chronus-CM-10-Clock-Caledner-widget.jpg

Best,

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Julien Delplanque

Re: Enhancing ICal library

On 13/05/15 11:02, Damien Cassou wrote:

> Hi Julien,
>
> Julien Delplanque <[hidden email]> writes:
>
>> Hi everyone,
>>
>> I took a little time to enhance the ICal library and to make it work
>> with Pharo 4!
>>
>> So I forked the one on smalltalkhub
>> (http://smalltalkhub.com/#!/~pdebruic/iCal) and put all the modified
>> code on github https://github.com/juliendelplanque/pharo-ical.
> that's great news, thank you very much for this work. This kind of
> library is very important. 2 suggestions:
>
> - could you please create a Jenkins job at
> https://ci.inria.fr/pharo-contribution/ to monitor the project?

Sure but I need an account how do I get one?
> - if you write your documentation in the next few weeks and in Pillar
> (http://www.smalltalkhub.com/#!/~Pier/Pillar), we might include the
> chapter in the next EnterprisePharo book (no promise, but iCal would
> fit well in the book theme). If you are not fast enough, we could
> still include it in one of the next books.
>

I'll probably write documentation next week if I find time (exams are
coming).
If I do, I'll write it in Pillar.
>> I already added a GTInspector extension to have better representation
>> of iCalendar when inspecting them in Pharo.
>
> A calendar view would be awesome (but probably a lot of work too :-)).
Yep it sounds cool :)
>
> A list of nicely-formatted events would already be great. Something
> along the lines of
> http://getandroidstuff.com/wp-content/uploads/2013/01/Chronus-CM-10-Clock-Caledner-widget.jpg
I already did this kind of stuff (attachments) but I'm not a designer so
it may not look as good as you want...

Julien

Capture =?windows-1252?Q?d=27=E9cran_de_2015-05-13_12-32-25=2Epng?= (338K) Download Attachment

Sean P. DeNigris

Re: Enhancing ICal library

Administrator

In reply to this post by Julien Delplanque

Julien Delplanque wrote

I took a little time to enhance the ICal library and to make it work
with Pharo 4!

Thanks!

Julien Delplanque wrote

I forked the one on smalltalkhub... I wanted to make it work on pharo 4... Url class that were deprecated in Pharo 3 and even removed on Pharo 4!

It's a shame to cut off Squeak users/potential-contributors due to a slightly different Url implementation. It seems like it wouldn't be too hard to simply abstract the url handling. But I understand we're all working for free and appreciate having it working in Pharo :) OTOH, I wonder if Zinc is loadable in Squeak? If so, making it cross-platform again might be as simple as adding a dependency to the config...

Cheers,
Sean

EstebanLM

Re: Enhancing ICal library

> On 13 May 2015, at 13:21, Sean P. DeNigris <[hidden email]> wrote:
>
> Julien Delplanque wrote
>> I took a little time to enhance the ICal library and to make it work
>> with Pharo 4!
>
> Thanks!
>
>
> Julien Delplanque wrote
>> I forked the one on smalltalkhub... I wanted to make it work on pharo 4...
>> Url class that were deprecated in Pharo 3 and even removed on Pharo 4!
>
> It's a shame to cut off Squeak users/potential-contributors due to a
> slightly different Url implementation. It seems like it wouldn't be too hard
> to simply abstract the url handling. But I understand we're all working for
> free and appreciate having it working in Pharo :) OTOH, I wonder if Zinc is
> loadable in Squeak? If so, making it cross-platform again might be as simple
> as adding a dependency to the config…

honestly, the more and more the time passes the less and less we are compatible… and this will increase will time.
if you want to keep compatibility you will have to provide compatibility abstractions and packages (in the same way Seaside uses Grease, etc.)

now… In this particular case I didn’t see any contributor from outside Pharo community… so is just an “abstract reflection”, not a reality… I would wait until some one in the Squeak community decides to use it and then it creates the compatibility layer (adding layers are usually a bad thing… specially when they are not necessary).

Esteban

>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Enhancing-ICal-library-tp4825990p4826156.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Stephan Eggermont-3

Re: Enhancing ICal library

On 13/05/15 13:44, Esteban Lorenzano wrote:
> honestly, the more and more the time passes the less and less we are compatible… and this will increase will time.
> if you want to keep compatibility you will have to provide compatibility abstractions and packages (in the same way Seaside uses Grease, etc.)
>
> now… In this particular case I didn’t see any contributor from outside Pharo community… so is just an “abstract reflection”, not a reality… I would wait until some one in the Squeak community decides to use it and then it creates the compatibility layer (adding layers are usually a bad thing… specially when they are not necessary).

In this case forking is a very bad idea.

It has been maintained by Paul for squeak, pharo and gemstone.
We know that not every library will be up to date as soon as a new
version of Pharo is released. Please dump the fork and make a
compatibility package.

Stephan

Damien Cassou-2

Re: Enhancing ICal library

In reply to this post by Julien Delplanque

Julien Delplanque <[hidden email]> writes:

>> A list of nicely-formatted events would already be great. Something
>> along the lines of
>> http://getandroidstuff.com/wp-content/uploads/2013/01/Chronus-CM-10-Clock-Caledner-widget.jpg
> I already did this kind of stuff (attachments) but I'm not a designer so
> it may not look as good as you want...

that's great! Thanks

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Julien Delplanque

Re: Enhancing ICal library

In reply to this post by Stephan Eggermont-3

So, I throw the fork on github and provide a compatibility package on
smalltalkhub?

I wanted to improve the lib, but I don't own it and there is no "pull
request" system on smalltalk hub.
I don't want to bother the owner of the repository with changes I want
to do. He probably has others things to do.

Also, I don't use and don't have interest in squeak and gemstone (for
the moment) so providing compatibility with pharo 2-3-4, squeak and
gemstone... I will not do that.

Finally, I already made some improvements in some objects of the model
part what should I do?

Regards,

Julien

On 13/05/15 15:03, Stephan Eggermont wrote:

> On 13/05/15 13:44, Esteban Lorenzano wrote:
>> honestly, the more and more the time passes the less and less we are
>> compatible… and this will increase will time.
>> if you want to keep compatibility you will have to provide
>> compatibility abstractions and packages (in the same way Seaside uses
>> Grease, etc.)
>>
>> now… In this particular case I didn’t see any contributor from
>> outside Pharo community… so is just an “abstract reflection”, not a
>> reality… I would wait until some one in the Squeak community decides
>> to use it and then it creates the compatibility layer (adding layers
>> are usually a bad thing… specially when they are not necessary).
>
> In this case forking is a very bad idea.
>
> It has been maintained by Paul for squeak, pharo and gemstone.
> We know that not every library will be up to date as soon as a new
> version of Pharo is released. Please dump the fork and make a
> compatibility package.
>
> Stephan
>
>
>

EstebanLM

Re: Enhancing ICal library

> On 13 May 2015, at 15:38, Julien Delplanque <[hidden email]> wrote:
>
> So, I throw the fork on github and provide a compatibility package on smalltalkhub?

It is not a demand. Just a suggestion. You can do whatever you want and nobody can impose you how to handle your code :)

Esteban

>
> I wanted to improve the lib, but I don't own it and there is no "pull request" system on smalltalk hub.
> I don't want to bother the owner of the repository with changes I want to do. He probably has others things to do.
>
> Also, I don't use and don't have interest in squeak and gemstone (for the moment) so providing compatibility with pharo 2-3-4, squeak and gemstone... I will not do that.
>
> Finally, I already made some improvements in some objects of the model part what should I do?
>
> Regards,
>
> Julien
>
> On 13/05/15 15:03, Stephan Eggermont wrote:
>> On 13/05/15 13:44, Esteban Lorenzano wrote:
>>> honestly, the more and more the time passes the less and less we are compatible… and this will increase will time.
>>> if you want to keep compatibility you will have to provide compatibility abstractions and packages (in the same way Seaside uses Grease, etc.)
>>>
>>> now… In this particular case I didn’t see any contributor from outside Pharo community… so is just an “abstract reflection”, not a reality… I would wait until some one in the Squeak community decides to use it and then it creates the compatibility layer (adding layers are usually a bad thing… specially when they are not necessary).
>>
>> In this case forking is a very bad idea.
>>
>> It has been maintained by Paul for squeak, pharo and gemstone.
>> We know that not every library will be up to date as soon as a new
>> version of Pharo is released. Please dump the fork and make a
>> compatibility package.
>>
>> Stephan
>>
>>
>>
>
>

Julien Delplanque

Re: Enhancing ICal library

Well, I don't think I'm going to create/keep the compatibility, the
purpose of the fork is to make it fully compatible with Pharo and I
don't want to be responsible of the compatibility with others smalltalk.

I also think that it's going to be harder and harder to keep
compatibility between Pharo and other smalltalk because (for example) of
packages that will be deprecated in an implementation and not in another
etc...

Julien

On 13/05/15 15:42, Esteban Lorenzano wrote:
>> On 13 May 2015, at 15:38, Julien Delplanque <[hidden email]> wrote:
>>
>> So, I throw the fork on github and provide a compatibility package on smalltalkhub?
> It is not a demand. Just a suggestion. You can do whatever you want and nobody can impose you how to handle your code :)
>
> Esteban
>

Sean P. DeNigris

Re: Enhancing ICal library

Administrator

In reply to this post by EstebanLM

EstebanLM wrote

It is not a demand. Just a suggestion. You can do whatever you want and nobody can impose you how to handle your code :)

+1. And to clarify, the suggestion is not that /you/ implement code for Squeak, Pharo, and Gemstone, but that you abstract a Url layer so that other interested parties can.

Cheers,
Sean

Sven Van Caekenberghe-2

Re: Enhancing ICal library

If it is just the Url class, then I can't imagine the difference between the old Url class and the new ZnUrl to be very large. An abstraction layer is probably not needed, both should understand #asUrl and should have quite a lot of common methods. The HTTP client is another story ;-)

On a more philosophical note, there is not much point in us trying to make Pharo better, adding new and improved API, and then not using it because external libraries must be compatible (of course this is the choice of the authors).

Also, doing things x-platform in Smalltalk is hard, especially if you do not use the other dialects. I would not want this to be a burden for newcomers to contribute.

Julien, talk again to Paul, you wil figure something out together, I am sure. If you need help to translate between the old and new, just ask.

Sven

> On 13 May 2015, at 16:03, Sean P. DeNigris <[hidden email]> wrote:
>
> EstebanLM wrote
>> It is not a demand. Just a suggestion. You can do whatever you want and
>> nobody can impose you how to handle your code :)
>
> +1. And to clarify, the suggestion is not that /you/ implement code for
> Squeak, Pharo, and Gemstone, but that you abstract a Url layer so that other
> interested parties can.
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Enhancing-ICal-library-tp4825990p4826198.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Stephan Eggermont-3

Re: Enhancing ICal library

In reply to this post by Julien Delplanque

On 13/05/15 15:38, Julien Delplanque wrote:
> So, I throw the fork on github and provide a compatibility package on
> smalltalkhub?

Yes. Forking is ok if it is difficult to maintain compatibility,
and that is definitely not the case here. Paul has made improvements
to the code a few months back, so it doesn't look like an abandoned
code base.

The Pharo support for git(hub) is not yet at the level where it
is easy to support forking smalltalkhub repos on github and merging
back. Soon, I hope.

> I wanted to improve the lib, but I don't own it and there is no "pull
> request" system on smalltalk hub.
> I don't want to bother the owner of the repository with changes I want
> to do. He probably has others things to do.

Don't need to. This is open source. You can commit in the repo.
Mailing lists are not as nice as pull requests for collaboration, but
work well enough.

> Also, I don't use and don't have interest in squeak and gemstone (for
> the moment) so providing compatibility with pharo 2-3-4, squeak and
> gemstone... I will not do that.

That is ok. The people using squeak, older pharo and gemstone will fix
their own problems. The only thing needed is separating between the
things you do in a generic package, and those you do in the pharo (4/5)
specific one.

> Finally, I already made some improvements in some objects of the model
> part what should I do?

Avoid making people do the work twice. This code is likely to be used
in production by some people, so needs to keep working in old versions too.

Stephan

Sean P. DeNigris

Re: Enhancing ICal library

Administrator

Stephan Eggermont wrote

This is open source. You can commit in the repo.

One point of confusion is probably that there is no indication (like we used to have in sqs) in StHub's web interface whether repos are publicly writable or not

Cheers,
Sean

Paul DeBruicker

Re: Enhancing ICal library

In reply to this post by Julien Delplanque

Hi Julien,

The only reason I mind that you forked it is that you now force every person that isn't yet using iCal in their project, but that wants to adopt it, to have to decide and evaluate both projects to see which one to adopt for their own use. So instead of you adopting the burden of integrating your changes with what exists you've pushed that decision onto all future potential users of iCal in Pharo. Which seems suboptimal.

That being said it is MIT licensed code, and you can do whatever you want with it.

What I did say to you on April 3 after giving you commit access to the iCal repo (which was not public because I forgot to flip the bit for that, fixed now tho) was:
"Right now it runs on Squeak, Pharo, and GemStone.

Please don't break them with your changes ;)

You should be able to ensure that the Pharo 4 specific stuff only loads into Pharo 4 without too much trouble."

I see now that that was vague. I was thinking that with the proper design & Metacello configuration your changes should be loadable no problem without breaking all the other dialects.

By the way, I've had a HTTPClient/Url cross dialect compatability package I've been maintaining here:

http://smalltalkhub.com/#!/~pdebruic/HTTPAPIClient

It could certainly use some attention but may have been helpful to your work on iCal.

Glad your making progress with the GTInspector and docs though. That ical spec (https://tools.ietf.org/html/rfc5545) is long and boring.

Julien Delplanque wrote

Hi everyone,

I took a little time to enhance the ICal library and to make it work
with Pharo 4!

So I forked the one on smalltalkhub
(http://smalltalkhub.com/#!/~pdebruic/iCal) and put all the modified
code on github https://github.com/juliendelplanque/pharo-ical.

Why did I forked? Well, I wanted to make it work on pharo 4 first, so I
contacted the owner of the smalltalkhub repository. He wanted to keep it
working on other smalltalk than Pharo. The problem was that the lib used
Url class that were deprecated in Pharo 3 and even removed on Pharo 4!
So I managed to repair the package using ZnUrl. Since I don't know if
the owner of this lib on Smalltalkhub have time to manage the problem to
keep the lib "multi-smalltalk", I have chosen to fork it so he can keep
his version compatible.

Good news are that I plan to keep it alive as long as I can, write some
documentation for it when I have time and even try to enhance it.

I already added a GTInspector extension to have better representation
of iCalendar when inspecting them in Pharo.

The version on master branch is supported by Pharo 2-3-4 (didn't check
with Pharo 1).

Regards,

Julien

Julien Delplanque

Re: Enhancing ICal library

Hi Paul,

So the abstraction layer already exists it's good.
Ok, so merging my changes to the original repository should not be that
hard. I'll check out how to do it and mail you when it's ready to be done.

I understand it will be annoying for people that have to choose between
the two ical framework. But, as I said before I'm ok to do some
improvements but only concerning the pharo side... Well, for this
library it shouldn't be that hard to use non-specific stuff I guess.

I'll keep you informed of what I'm doing :)

Regards,

Julien

On 16/05/15 17:04, Paul DeBruicker wrote:

> Hi Julien,
>
> The only reason I mind that you forked it is that you now force every person
> that isn't yet using iCal in their project, but that wants to adopt it, to
> have to decide and evaluate both projects to see which one to adopt for
> their own use. So instead of you adopting the burden of integrating your
> changes with what exists you've pushed that decision onto all future
> potential users of iCal in Pharo. Which seems suboptimal.
>
>
> That being said it is MIT licensed code, and you can do whatever you want
> with it.
>
>
> What I did say to you on April 3 after giving you commit access to the iCal
> repo (which was not public because I forgot to flip the bit for that, fixed
> now tho) was:
> "Right now it runs on Squeak, Pharo, and GemStone.
>
>
> Please don't break them with your changes ;)
>
>
> You should be able to ensure that the Pharo 4 specific stuff only loads into
> Pharo 4 without too much trouble."
>
> I see now that that was vague. I was thinking that with the proper design &
> Metacello configuration your changes should be loadable no problem without
> breaking all the other dialects.
>
>
> By the way, I've had a HTTPClient/Url cross dialect compatability package
> I've been maintaining here:
>
> http://smalltalkhub.com/#!/~pdebruic/HTTPAPIClient
>
> It could certainly use some attention but may have been helpful to your work
> on iCal.
>
>
> Glad your making progress with the GTInspector and docs though. That ical
> spec (https://tools.ietf.org/html/rfc5545) is long and boring.
>
>
>
>
> Julien Delplanque wrote
>> Hi everyone,
>>
>> I took a little time to enhance the ICal library and to make it work
>> with Pharo 4!
>>
>> So I forked the one on smalltalkhub
>> (http://smalltalkhub.com/#!/~pdebruic/iCal) and put all the modified
>> code on github https://github.com/juliendelplanque/pharo-ical.
>>
>> Why did I forked? Well, I wanted to make it work on pharo 4 first, so I
>> contacted the owner of the smalltalkhub repository. He wanted to keep it
>> working on other smalltalk than Pharo. The problem was that the lib used
>> Url class that were deprecated in Pharo 3 and even removed on Pharo 4!
>> So I managed to repair the package using ZnUrl. Since I don't know if
>> the owner of this lib on Smalltalkhub have time to manage the problem to
>> keep the lib "multi-smalltalk", I have chosen to fork it so he can keep
>> his version compatible.
>>
>> Good news are that I plan to keep it alive as long as I can, write some
>> documentation for it when I have time and even try to enhance it.
>>
>> I already added a GTInspector extension to have better representation
>> of iCalendar when inspecting them in Pharo.
>>
>> The version on master branch is supported by Pharo 2-3-4 (didn't check
>> with Pharo 1).
>>
>> Regards,
>>
>> Julien
>
>
>
>
> --
> View this message in context: http://forum.world.st/Enhancing-ICal-library-tp4825990p4826767.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>