[Pharo-users] GSoC: call for ideas
Hi fellow Pharo hackers, ESUG, the European Smalltalk User Group, is applying for this year's Google Summer of Code. As you probably know, the Summer of Code provides the opportunity to fund students to work during the summer on Pharo. Please reply to this email (be sure to use Reply to all) if you have ideas you would like to propose. Please include a summary of the project and links to web pages that can help prospective students to write their application. Please also include the following information: - if applicable, other dialects that you would be willing to mentor this project for - the skill level - name of the mentor(s), email addresses, and possibly any IRC network/channel/nickname where they can be found. Thanks for contributing to ESUG's Summer of Code application! -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-users] [gsoc-mentors] Re: GSoC: call for ideas
Ahh I started a while ago another thread that said Pharo in the subject as adviced! :/ Should we keep this one or that one? On Tue, Feb 11, 2014 at 10:59 AM, Damien Cassou damien.cas...@gmail.comwrote: Project idea Description: Make Pharo a scripting language with its syntax and command-line tools (http://rmod.lille.inria.fr/coral/) Skill level: intermediate Name of the mentor: Damien Cassou damien.cas...@gmail.com, DamienCassou on IRC (freenode) On Tue, Feb 11, 2014 at 10:42 AM, Damien Cassou damien.cas...@gmail.com wrote: Hi fellow Pharo hackers, ESUG, the European Smalltalk User Group, is applying for this year's Google Summer of Code. As you probably know, the Summer of Code provides the opportunity to fund students to work during the summer on Pharo. Please reply to this email (be sure to use Reply to all) if you have ideas you would like to propose. Please include a summary of the project and links to web pages that can help prospective students to write their application. Please also include the following information: - if applicable, other dialects that you would be willing to mentor this project for - the skill level - name of the mentor(s), email addresses, and possibly any IRC network/channel/nickname where they can be found. Thanks for contributing to ESUG's Summer of Code application! -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- You received this message because you are subscribed to the Google Groups Smalltalk GSoC mentors group. To unsubscribe from this group and stop receiving emails from it, send an email to smalltalk-gsoc-mentors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Pharo-users] [gsoc-mentors] GSoC: call for ideas
- (*Intermediate*) *Amber* - *Pharo* interaction via WebSocket. Specifically, Pharo as IDE for Amber -- as continuation of http://gsoc2013.esug.org/projects/amber-tools and http://gsoc2012.esug.org/projects/mmi-amber. Use new tools (Glamorous Toolkit, for example). - (*Advanced*) Boundless and zoomable interfaces with *Pharo*. Continuation of http://gsoc2012.esug.org/projects/esse using Athens [ https://code.google.com/p/pharo/wiki/Athens]. This can be further development of the Esse presentation framework, or creating some development tools for Pharo. - (*Intermediate*) Implementation of Object Semantic Networks as a new knowledge-representation engine to be used inside *Pharo* (for various purposes). This task can include development of web interface for the system using *Amber*. Please, contact me directly for details. Dennis Schetinin email: chae...@gmail.com skype: dennis.schetinin -- Best regards, Dennis Schetinin 2014-02-11 13:42 GMT+04:00 Damien Cassou damien.cas...@gmail.com: Hi fellow Pharo hackers, ESUG, the European Smalltalk User Group, is applying for this year's Google Summer of Code. As you probably know, the Summer of Code provides the opportunity to fund students to work during the summer on Pharo. Please reply to this email (be sure to use Reply to all) if you have ideas you would like to propose. Please include a summary of the project and links to web pages that can help prospective students to write their application. Please also include the following information: - if applicable, other dialects that you would be willing to mentor this project for - the skill level - name of the mentor(s), email addresses, and possibly any IRC network/channel/nickname where they can be found. Thanks for contributing to ESUG's Summer of Code application! -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- You received this message because you are subscribed to the Google Groups Smalltalk GSoC mentors group. To unsubscribe from this group and stop receiving emails from it, send an email to smalltalk-gsoc-mentors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Pharo-users] Using/editing external packages..
i am currenty develop an app in seaside, and am wondering about best practices when using external packages. in my case, i am using a copy of TF-Login that i updated to work in pharo 2. The main class in that package is RegisteredUser. as is true in most cases, i will be tweaking this object a great deal. this package also contains a great deal of renderers that will be tweaked. so, my question is: how should i go about this? should i take RegisteredUser and sublcass it? this might requried me to change other code in the package? should i subclass the renders and override their methods? should i just go ahead and edit the TF-Login package directly? my initial thought was to edit the package direclty, but i am not sure what would happen if the package is externally updated. thoughts? ideas? -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
Re: [Pharo-users] [Pharo-dev] GSoC: call for ideas
Hey guys. 1. Implicit variable declarations support in FAST Make FAST to work with one of the languages that do not have explicit declaration of variables. Preferable target language is Javascript. This should move FAST to new horizons. advanced Yuriy Tymchuk yuriy.tymc...@me.com, Anne Etien anne.et...@univ-lille1.fr 2. Interaction API for Roassal. Provide a nice api of Roassal to filter, select, delete, group… etc elements. This will be extra useful for reverse engineering tools. advanced - complex Alexandre Bergel alexandre.ber...@me.com, Yuriy Tymchuk yuriy.tymc...@me.com 3. Tools to work with resources (non-text data). Even if serialising it as code is not a good solution we can make tools to load, serialise resources to code… easy - advanced Yuriy Tymchuk yuriy.tymc...@me.com 4. Preferences persistence. Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: “Save for all next images”. This way we won’t have a lot of clones in monticello and make user’s life easier. You can use a startup scripts, but this is not cool. easy - advanced Yuriy Tymchuk yuriy.tymc...@me.com Cheers Uko On 11 Feb 2014, at 10:42, Damien Cassou damien.cas...@gmail.com wrote: Hi fellow Pharo hackers, ESUG, the European Smalltalk User Group, is applying for this year's Google Summer of Code. As you probably know, the Summer of Code provides the opportunity to fund students to work during the summer on Pharo. Please reply to this email (be sure to use Reply to all) if you have ideas you would like to propose. Please include a summary of the project and links to web pages that can help prospective students to write their application. Please also include the following information: - if applicable, other dialects that you would be willing to mentor this project for - the skill level - name of the mentor(s), email addresses, and possibly any IRC network/channel/nickname where they can be found. Thanks for contributing to ESUG's Summer of Code application! -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
[Pharo-users] branching with monticello
i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name like update_user_functions.. we develop away on that, and when it's time, we merge that back into master, and push out to the server. having named branches makes it very easy for us track what's going on in the development line. is this possible with monticello, or am i just missing an ideology? thanks! -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
Re: [Pharo-users] Using/editing external packages..
sergio_101 wrote i am currenty develop an app in seaside, and am wondering about best practices when using external packages. I've found the easiest and most flexible approach is two-fold: - Refactor the underlying library with the hooks and abstractions you need - And then, subclass If you just override and monkey-patch, I feel you are more vulnerable to the library changing underneath you, as well is potentially making your code harder to understand. If you can make the library designed to use it the way you want, you will reduce duplication and the chance of someone else coming in and doing it in an incompatible way, as well as give the library maintainers an idea of what you're doing, so they may consider that in making non-backward-compatible changes. Of course, that's ideal and requires library maintainers open to accepting such changes, but in practice I've found this to be true (with Pharo, Magritte, BabyMock…) - Cheers, Sean -- View this message in context: http://forum.world.st/Using-editing-external-packages-tp4742801p4742832.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] branching with monticello
sergio_101 wrote is this possible with monticello, or am i just missing an ideology? There's not really first class branching in MC. The convention, which is somewhat supported by the tools, is to include an extra segment like this. If you want an issue101 branch, you save the package as MyPackage.issue101.MyName.mcz (instead of just MyPackage.MyName.mcz). IIRC these would be listed separately in the MC tools at least... - Cheers, Sean -- View this message in context: http://forum.world.st/branching-with-monticello-tp4742815p4742840.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] branching with monticello
in monticello, each package is itself a branch. so you can have different approachs: - you just rename your package to YourPackage-YourBranch - you use different repositories - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) Esteban On 11 Feb 2014, at 16:46, sergio_101 sergio@gmail.com wrote: i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name like update_user_functions.. we develop away on that, and when it's time, we merge that back into master, and push out to the server. having named branches makes it very easy for us track what's going on in the development line. is this possible with monticello, or am i just missing an ideology? thanks! -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
Re: [Pharo-users] branching with monticello
Can we get something from git branches with file tree? Uko On 11 Feb 2014, at 17:26, Esteban Lorenzano esteba...@gmail.com wrote: in monticello, each package is itself a branch. so you can have different approachs: - you just rename your package to YourPackage-YourBranch - you use different repositories - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) Esteban On 11 Feb 2014, at 16:46, sergio_101 sergio@gmail.com wrote: i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name like update_user_functions.. we develop away on that, and when it's time, we merge that back into master, and push out to the server. having named branches makes it very easy for us track what's going on in the development line. is this possible with monticello, or am i just missing an ideology? thanks! -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
Re: [Pharo-users] Using/editing external packages..
i think you're right.. i just need to sit down and walk myself through it with this codebase.. since i am the maintainer of the codebase in question (although i did not write it), i really want to address this issue correctly, and not cut any corners.. thanks! On Tue, Feb 11, 2014 at 11:20 AM, Sean P. DeNigris s...@clipperadams.comwrote: sergio_101 wrote i am currenty develop an app in seaside, and am wondering about best practices when using external packages. I've found the easiest and most flexible approach is two-fold: - Refactor the underlying library with the hooks and abstractions you need - And then, subclass If you just override and monkey-patch, I feel you are more vulnerable to the library changing underneath you, as well is potentially making your code harder to understand. If you can make the library designed to use it the way you want, you will reduce duplication and the chance of someone else coming in and doing it in an incompatible way, as well as give the library maintainers an idea of what you're doing, so they may consider that in making non-backward-compatible changes. Of course, that's ideal and requires library maintainers open to accepting such changes, but in practice I've found this to be true (with Pharo, Magritte, BabyMock...) - Cheers, Sean -- View this message in context: http://forum.world.st/Using-editing-external-packages-tp4742801p4742832.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
Re: [Pharo-users] branching with monticello
Hi, On 11 Feb 2014, at 19:16, Yuriy Tymchuk yuriy.tymc...@me.com wrote: I’m worried a bit about merging. Won’t it damage some monticello meta data? If you start with 2 version with correct meta data and ancestries, no. This could be helpful: http://www.lukas-renggli.ch/blog/monticello-merging It all sounds very magic, but it is quite simple. Apart from the fact that merging often means fixing conflicts. That is true everywhere. Sven Uko On 11 Feb 2014, at 18:22, Esteban Lorenzano esteba...@gmail.com wrote: you can… filetree is a file format. What you do with those files is up to you and your tools :) On 11 Feb 2014, at 17:30, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Can we get something from git branches with file tree? Uko On 11 Feb 2014, at 17:26, Esteban Lorenzano esteba...@gmail.com wrote: in monticello, each package is itself a branch. so you can have different approachs: - you just rename your package to YourPackage-YourBranch - you use different repositories - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) Esteban On 11 Feb 2014, at 16:46, sergio_101 sergio@gmail.com wrote: i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name like update_user_functions.. we develop away on that, and when it's time, we merge that back into master, and push out to the server. having named branches makes it very easy for us track what's going on in the development line. is this possible with monticello, or am i just missing an ideology? thanks! -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
[Pharo-users] [ANN] ScriptManager 1.7 Release for upcoming Pharo 3.0
Thanks to Sven van Caekenberghe the ScriptManager tool hosted in project http://smalltalkhub.com/#!/~TorstenBergmann/ScriptManager/ now also provides the ability to import/export not only to a single binary fuel file but also to a folder with readable scripts. This is a good idea and may also help to use external editors or versioning systems like git or others on the custom scripts. I also reworked the menues to be in alignment with the common style and polished the package for Pharo 3.0 as a new release version 1.7. Just open the config browser in Pharo 3.0 and load ScriptManager. After loading it will be available under Tools - ScriptManager. Have fun T.
Re: [Pharo-users] [Pharo-dev] [ANN] ScriptManager 1.7 Release for upcoming Pharo 3.0
Hi Torsten, On 11 Feb 2014, at 22:12, Torsten Bergmann asta...@gmx.de wrote: Thanks to Sven van Caekenberghe the ScriptManager tool hosted in project http://smalltalkhub.com/#!/~TorstenBergmann/ScriptManager/ now also provides the ability to import/export not only to a single binary fuel file but also to a folder with readable scripts. This is a good idea and may also help to use external editors or versioning systems like git or others on the custom scripts. I also reworked the menues to be in alignment with the common style and polished the package for Pharo 3.0 as a new release version 1.7. Just open the config browser in Pharo 3.0 and load ScriptManager. After loading it will be available under Tools - ScriptManager. Have fun T. Thanks for including this. The only 'issue' that I had is that the line end convention used for writing the workspaces is CR (at least on my Mac), which is not cool when you want to work with the files outside the image (should be Unix style LF). Now, the File Browser does the same when creating files, as does Workspace when exporting. That is why I left it like that. BTW: I have been using your Bootstrap code all day long and it is seriously cool - I will have feedback in the coming weeks ;-) Sven
[Pharo-users] smalltalkhub.com - commits history
i have a few projects i am playing with smalltalkhub on, but i am not sure if i am doing it right.. if i look under commits, i see no commit history, but under source, i can see about 35 different versions of the source i have committed. any ideas? thanks! -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
Re: [Pharo-users] smalltalkhub.com - commits history
What is your repo, so that we can have a look. What you say doesn't look normal. There should be versions listed in both. Phil On Wed, Feb 12, 2014 at 5:00 AM, sergio t. ruiz sergio@gmail.comwrote: i have a few projects i am playing with smalltalkhub on, but i am not sure if i am doing it right.. if i look under commits, i see no commit history, but under source, i can see about 35 different versions of the source i have committed. any ideas? thanks! -- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
