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
Hi Julien, Julien Delplanque <julien@tamere.eu> 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-Ca... Best, -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
On 13/05/15 11:02, Damien Cassou wrote:
Hi Julien,
Julien Delplanque <julien@tamere.eu> 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-Ca... 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
Julien Delplanque <julien@tamere.eu> 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-Ca... 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 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 -- 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.
On 13 May 2015, at 13:21, Sean P. DeNigris <sean@clipperadams.com> 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.
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
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
On 13 May 2015, at 15:38, Julien Delplanque <julien@tamere.eu> 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
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 <julien@tamere.eu> 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
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.
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 <sean@clipperadams.com> 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.
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
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 -- View this message in context: http://forum.world.st/Enhancing-ICal-library-tp4825990p4826255.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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.
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.
participants (7)
-
Damien Cassou -
Esteban Lorenzano -
Julien Delplanque -
Paul DeBruicker -
Sean P. DeNigris -
Stephan Eggermont -
Sven Van Caekenberghe