Re: [Pharo-users] Metacello GIT methodProperties.json
On 04/08/2015 12:47 PM, Thierry Goubier wrote: Hi Dale, Le 08/04/2015 19:30, Dale Henrichs a écrit : On 04/07/2015 10:24 PM, Thierry Goubier wrote: Le 08/04/2015 02:05, Dale Henrichs a écrit : I have threatened in the past to add an option to a repository that would eliminate the need to store monticello meta data ... Damien is working on starting from scratch on the new format, because the current implementation supports 4-5 different FileTree formats. Damien's work could be leveraged to add an optional Monticello meta data option to FileTree and if your SCM (like git) gives you per method history with the proper tools you can leverage that information.. I would say this could be a reasonable possibility, in that you could have two modes of compatibility: - Complete filetree compatibility for gitfiletree: the current situation, with properties and version written to disk. - Partial filetree compatibility, where that metadata isn't written and you rely on gitfiletree to recreate it to export as .mcz. Partial compatibility has two effects, which need to be considered. When using github:// or bitbucket:// urls, filetree will be used and your packages will end up having no version number (except .1?), no author, no timestamps for methods, etc... And the second one is that, if you clone a mcz inside the gitfiletree repository, the mcz ancestry of versions and author timestamps on methods will be lost, which is something you may not want. Yes for Metacello some modifications would need to be made because in a normal mcz universe Metacello will not load a package if the version is older or the same as the one in the image ... and following in the tradition of other Monticello tools the UUID is ignored:( .. I was working with a pure cypress implementation and have written the Metacello code to support these repos ... Ok. Yes, the version number handling is delicate; even the one used by gitfiletree feels unsatisfying, even if it allows Metacello/Monticello to work as usual. The work I had done was at the Metacello level and is in the Metacello-Cypress package where I changed the load semantics to unconditionally load the package ... the snapshot comparison logic in play when loading packages is pretty good so it isn't necessarily a penalty to unconditionally compare snapshots when loading a package from FileTree ... A better long term solution is to treat these as a CypressPackage or FileTreePackage which has some similarities to Monticello packages ... because faking out Monitcello version numbers and users is not much different than storing the metadata in FileTree ... Not sure I understand. I know where the Cypress/FileTree code handles the lack of metadata when reading, that's all :) But someone were to add those options to filetree, I think we could reduce the overall number of hacks:) Another solution I'd see possible is a reduced metadata format, where just the version number of the current package is stored and retrieved (i.e. a version file without ancestry). It would allow FileTree and Metacello to work exactly as usual. And, maybe, I could even unify the UUIDs? There are things in Monticello which needs a rethink to better adapt to SCMs like git (or Fossil: it's so similar to git :) ) while keeping more or less the same appearance: branches, hashes, tags and semantic versionning. But I don't see yet how to handle that or to propose anything. I know that it would be great to reduce the cognitive distance between MC version and history handling, and the same as seen from Metacello baselines and configurations. Branches + baselines are doing a lot to simplify, but MC stuff is unaware of that. And MC should delegate merging to the underlying repository, as well. So this extraneous Monticello meta data is really related to the versioning aspects of the Monticello package ... aspects that really needed if you are using git (read git as svn, hg, git, fossil, etc.:) for version control .. in working with git the SHA of the commit for the repository as a whole is more important than any of the package meta data ... from the SHA one can see the commit comment for the git commit the SHA is related to a project not a package ... the project contents is represented by the BaselineOf ... in git one can reason about the collection of commits associated with a directory (package or class or method) and look at diffs at that level of granularity The primary point being that a git package can be stripped down to the basic list of definitions and the ancestry and version names and method properties can be dropped on the floor instead of fabricated ... What I imagine is a separate software stack for these git packages the commonality is at the snapshot/definition level and the core definitions can migrate between Monticello and git packages almost without change ... if one wanted to know the history of a package the Monticello package would
Re: [Pharo-users] Metacello GIT methodProperties.json
On 04/08/2015 01:11 AM, Thierry Goubier wrote: 2015-04-08 8:47 GMT+02:00 Peter Uhnák i.uh...@gmail.com mailto:i.uh...@gmail.com: I thnk that rather than focus on the disk format which I hardly ever actually look at ... that folks should be looking at tools support (like Thierry) ... this is where the real work needs to happen ... good tools can hide the disk fomat completely so why does the disk format matter ... I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. Agreed and this is in that spirit I did GitFileTree. Dale went a bit further and even integrated the git command line access inside smalltalk via CommandShell... so that you get the best of both worlds without leaving your beloved Smalltalk :) Actually it is not quite CommandShell based ... the shell is tODE shell, where Smalltalk is the scripting language. The tODE git commands are implemented by parsing the command line args, resolving options and args to objects, and then calling a Smalltalk git command API that eventually does make shell calls (sometimes multiple git commands are folded into a single tODE git command ... thus making it possible to ultimately switch out the actual `git calls` and use something FFI-based, like libgit2... This approach also makes it quite feasible to write fairly complicated Smalltalk scripts that call the smalltalk git command api directly, bypassing the command line interface altogether ... As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included). Well, as I said elsewhere, Smalltalk doesn't work like that: code has to be lived in the image for most tools to work properly... it doesn't really have an editor of file mindset, but an object inspector mindset. What we're looking at in another thread is how to emulate that live object approach over dead files, and, thinking of it, I'm not sure we will succeed well. In short, what you want may never work properly because it is not how it should be conceptualized. In tODE I regularly drop off live objects to the file system using STON ... The tODE shell which allows you to navigate an object-based directory also allows you to mount the nodes from the file system and when traversing the file system recognizes STON files and presents objects to you instead of the dead files:) I haven't tried taking this approach all the way to source files ... but Dale
Re: [Pharo-users] Opening SettingBrowser on custom settings
Mmmm, the second option takes for me a while to open, i'll try using the
first option adding an argument to the pragma.
On Wed, Apr 8, 2015 at 7:25 PM, Laura Risani laura.ris...@gmail.com wrote:
Hi Alain , hi Nicolai, thank you for your answers.
In fact what i need is to parametrically show all settings i defined on a
package, so i'll do the second.
On Wed, Apr 8, 2015 at 6:23 PM, Nicolai Hess nicolaih...@web.de wrote:
2015-04-08 18:34 GMT+02:00 Laura Risani laura.ris...@gmail.com:
Hi all,
Say that i wanted to open a SettingBrowser showing only the settings
defined by 'SystemSystemSettings class systemSettingOn:' . How could i
do that?
There is a method 'SettingBrowser browse:' . Based on it's comment i
tried adding to systemSettingOn: the pragma banana, and then sending
' SettingBrowser browse:#('banana') ' but it didn't work.
Most (all?) settings use the pragma systemsettings, that means you can
not filter by the pragma keyword, to only get the settings for one
subcategory in the default settings.
But if the settings you want to display are all from one Package, you can
browse only settings from that package:
(SettingBrowser new setViewedPackageNames: 'Settings-System')
open;
expandAll
Best,
Laura
Re: [Pharo-users] Opening SettingBrowser on custom settings
Hi Alain , hi Nicolai, thank you for your answers.
In fact what i need is to parametrically show all settings i defined on a
package, so i'll do the second.
On Wed, Apr 8, 2015 at 6:23 PM, Nicolai Hess nicolaih...@web.de wrote:
2015-04-08 18:34 GMT+02:00 Laura Risani laura.ris...@gmail.com:
Hi all,
Say that i wanted to open a SettingBrowser showing only the settings
defined by 'SystemSystemSettings class systemSettingOn:' . How could i
do that?
There is a method 'SettingBrowser browse:' . Based on it's comment i
tried adding to systemSettingOn: the pragma banana, and then sending '
SettingBrowser
browse:#('banana') ' but it didn't work.
Most (all?) settings use the pragma systemsettings, that means you can
not filter by the pragma keyword, to only get the settings for one
subcategory in the default settings.
But if the settings you want to display are all from one Package, you can
browse only settings from that package:
(SettingBrowser new setViewedPackageNames: 'Settings-System')
open;
expandAll
Best,
Laura
Re: [Pharo-users] Metacello GIT methodProperties.json
On 04/08/2015 04:23 AM, Sean P. DeNigris wrote: Dale Henrichs-3 wrote Dale Henrichs-3 wrote I am really pressed for time so I don't have the luxury to blue sky ideas ... I understand. I was not suggesting anyone do anything. Also, I agree that methods seem to be the proper level for SCM versioning as they are in the Smalltalk image. I was simply asking, in light of the appearance that the merge driver could seemingly ignore the changes to certain files while still committing them with Git, if it would be feasible to add read-only one-class-per files for viewing on GitHub. This is more of a sanity check to see if I understood what the merge driver makes possible. Sean, I think the issue becomes one of so who makes sure the the readonly file matches the rest of the source ... I do occasionally edit files directory with vi ... I do regularly merge in changes from GemStone and Squeak ... so any package with this kind of file has the potential to decay quickly unless the changes were made so that they'd work on the supported filetree platforms ... If you wanted to experiment, you could fork FileTree and try some experiments ... if they become something worth sharing, they could be merged into the master pharo branch ... Dale
Re: [Pharo-users] class variable accessor naming
You can find many guidelines like these in the Smalltalk with Style book. For instance on page 3 it says Upper and lowercase letters also distinguish variable scope. Variables beginning with an upper case letter (globals, classes, *class variables*, and pool dictionaries) are global to all methods within the definition scope of the variable. Method parameters, temporary variables, and instance variables begin with a lower case letter. By convention, *class and instance method names* begin with a lower case letter. You can find this and other Smalltalk books here: http://stephane.ducasse.free.fr/FreeBooks.html Christian On Wed, Apr 8, 2015 at 3:13 PM, Jan B. blizn...@fit.cvut.cz wrote: True, I already found few examples of accessors to class variables, but I like to be sure when I use it for the first time. Thank you. Jan Christian Caldeiro wrote Class variables should be written with Uppercase (but there are some classes in Pharo that don't follow this convention). Class methods (accessors in this case) are written in lowercase. Again, you can find several samples in Pharo. Thanks Christian On Tue, Apr 7, 2015 at 1:54 PM, Jan B. lt; bliznjan@.cvut gt; wrote: Hello Class variable names should start with capital letter (as I just found out), like RecentProjects. We have a getter to it. Should such accessor method be named recentProjects or RecentProjects? ... class#(r/R)ecentProjects ^ RecentProjects Jan -- View this message in context: http://forum.world.st/class-variable-accessor-naming-tp4818137.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/class-variable-accessor-naming-tp4818137p4818431.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Opening SettingBrowser on custom settings
2015-04-08 18:34 GMT+02:00 Laura Risani laura.ris...@gmail.com:
Hi all,
Say that i wanted to open a SettingBrowser showing only the settings
defined by 'SystemSystemSettings class systemSettingOn:' . How could i
do that?
There is a method 'SettingBrowser browse:' . Based on it's comment i
tried adding to systemSettingOn: the pragma banana, and then sending '
SettingBrowser
browse:#('banana') ' but it didn't work.
Most (all?) settings use the pragma systemsettings, that means you can
not filter by the pragma keyword, to only get the settings for one
subcategory in the default settings.
But if the settings you want to display are all from one Package, you can
browse only settings from that package:
(SettingBrowser new setViewedPackageNames: 'Settings-System')
open;
expandAll
Best,
Laura
Re: [Pharo-users] Opening SettingBrowser on custom settings
---BeginMessage---
Le 8 avr. 2015 à 18:34, Laura Risani laura.ris...@gmail.com a écrit :
Hi all,
Say that i wanted to open a SettingBrowser showing only the settings defined
by 'SystemSystemSettings class systemSettingOn:' . How could i do that?
There is a method 'SettingBrowser browse:' . Based on it's comment i tried
adding to systemSettingOn: the pragma banana, and then sending '
SettingBrowser browse:#('banana') ' but it didn't work.
Hello Laura,
try this:
SettingTreeBuilderbanana
settingPragmaProcessor
Process a banana pragma »
banana just works as a regular setting
^ self systemsettings
then define your banana settings:
BananaSetting classmyBananaSettingOn: aBuilder
banana
(aBuilder group: #Banana)
then try:
SettingBrowser browse: #('banana’)
Best,
Laura
---End Message---
Re: [Pharo-users] Eating your own dog food (Site/Blog)
I started to work on using pillar to do that but nothing ready for people to use. I will work on it at Lviv or during my vacations just after. I want to use it for my website. Right now parts of it are automatically generated from Pharo. Stef Le 7/4/15 10:56, Yuriy Tymchuk a écrit : Oh, I knew that there was a discussion about that, but couldn’t find where. Still, is anybody else using Marina except for Pharo website? Uko On 07 Apr 2015, at 10:45, Damien Cassou damien.cas...@gmail.com wrote: Yuriy Tymchuk yuriy.tymc...@me.com writes: if I want to create a site/blog in pharo… What do I use? I know that there is Pier, but when you check its webpage, the last update is in 2011. Pharo website is built with Marina, but when I check the repo, the last commit was done by me and it was 2 month ago. Will Marina continue to evolve? And is anyone else using Marina? http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615.html -- 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] Metacello GIT methodProperties.json
I thnk that rather than focus on the disk format which I hardly ever actually look at ... that folks should be looking at tools support (like Thierry) ... this is where the real work needs to happen ... good tools can hide the disk fomat completely so why does the disk format matter ... I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included). But to bottom line this thread (for me at least, because I'm getting lost): 1. methodProperties.json provide compatibility for FileTree, so I don't want to get rid of it (for now) 2. the large amount of file changes is probably a bug (I'll try to be more observant about the commits in the future and hopefully some pattern will emerge.) 3. I shouldn't want to break things for now at least 4. more people are starting to work on Git 5. I need to learn about FileTree at some point if I want to contribute and experiment with (my) ideas (which won't be soon as I'm preparing for my finals) Thanks for all your answers. Peter On Wed, Apr 8, 2015 at 7:24 AM, Thierry Goubier thierry.goub...@gmail.com wrote: Le 08/04/2015 02:05, Dale Henrichs a écrit : Peter, That looks like a bug in the FileTree writer ... wiht one method change there should have been only one method property file change ... Yes, I'd agree. This is surprising. Unless you had been loading that package via another repository / another version / another branch before in the same image? MCMethodDefinition has a cache which consider equals methods with different timestamps, and, in that case, it would carry the timestamps of the previous version, and writing those upon save instead of the originals. Peter and Sean, If you are interested in contributing code/bugfixes to FileTree, I will welcome pull requests ... As I have mentioned in several posts today, I do not have the time to fiddle with changes to the FileTree format myself, but I welcome contributions. Damien has started work on an updated version of the FileTree format[2]. I have threatened in the past to add an option to a repository that would eliminate the need to store monticello meta data ... Damien is working on starting from scratch on the new format, because the current implementation supports 4-5 different FileTree formats. Damien's work could be leveraged to add an optional Monticello meta data option to FileTree and if your SCM (like git) gives you per method history with the proper tools you can leverage that information.. I would say this could be a reasonable possibility, in that you could have two modes of compatibility: - Complete filetree compatibility for gitfiletree: the current situation, with properties and version written to disk. - Partial filetree compatibility, where that metadata isn't written and you rely on gitfiletree to recreate it to export as .mcz. Partial compatibility has two effects, which need to be considered. When using github:// or bitbucket:// urls, filetree will be used and your packages will end up having no version number (except .1?), no author, no timestamps for methods, etc... And the second one is that, if you clone a mcz inside the gitfiletree repository, the mcz ancestry of versions and author timestamps on methods will be lost, which is something you may not want. Thierry As I ranted in another post ... changing the disk format is the easy part ... building and maintaining tools for the 4-5 different Smalltalk dialects is a different matter ... Dale [1] https://github.com/dalehenrich/filetree/issues [2] https://github.com/dalehenrich/filetree/issues/144 On 04/07/2015 04:38 PM, Peter Uhnák wrote: Yeah, I do use the MergeDriver and it saved me a lot of headache, but when I see things like this https://github.com/dynacase/dynacase/commit/ 90141d63bfdd433e51a768c2191e035b76c5da83 where one five lines long method generated 14 file changes with 180 additions and 172 deletions... it makes the log on github and pull requests incredibly messy. I don't want to cut branch under myself if I were to remove the properties file. So my question now is: how hard would it be to regenerate those files? Or maybe if it was moved to some metadirectory. This reminds me a bit of svn which polluted the whole folder tree with .svn files everywhere. Peter On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris s...@clipperadams.com mailto:s...@clipperadams.com wrote: Dale Henrichs-3 wrote
Re: [Pharo-users] GitHub Mirror Workflow
Bump :) Sean P. DeNigris wrote for the Mirror on Github use case, I wonder if less granularity wouldn't clearly be more appropriate. I read about using chunk format (not ideal, but perhaps a bit more readable on the mirror) via Gitocello, but loading in Pharo 4.0 broke on the FFI dependency. Any thoughts/suggestions? - Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818339.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Eating your own dog food (Site/Blog)
When are you going to be in Lviv? On 08 Apr 2015, at 08:32, stepharo steph...@free.fr wrote: I started to work on using pillar to do that but nothing ready for people to use. I will work on it at Lviv or during my vacations just after. I want to use it for my website. Right now parts of it are automatically generated from Pharo. Stef Le 7/4/15 10:56, Yuriy Tymchuk a écrit : Oh, I knew that there was a discussion about that, but couldn’t find where. Still, is anybody else using Marina except for Pharo website? Uko On 07 Apr 2015, at 10:45, Damien Cassou damien.cas...@gmail.com wrote: Yuriy Tymchuk yuriy.tymc...@me.com writes: if I want to create a site/blog in pharo… What do I use? I know that there is Pier, but when you check its webpage, the last update is in 2011. Pharo website is built with Marina, but when I check the repo, the last commit was done by me and it was 2 month ago. Will Marina continue to evolve? And is anyone else using Marina? http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615.html -- 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] happy easter :-)
I got the icon from http://iconmonstr.com I simply use the path in roassal Alexandre On Apr 8, 2015, at 3:34 AM, kilon alios kilon.al...@gmail.com wrote: Not if you are Orthodox Christian ;) Happy Easter , great graphic. Did you do it by hand or you used a vector app like inkscape ? On Wed, Apr 8, 2015 at 2:08 AM, Alexandre Bergel alexandre.ber...@me.com wrote: A few days late :-) http://ws.stfx.eu/B8D2V8TO8BIE Screen Shot 2015-04-07 at 8.08.03 PM.png -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-users] Metacello GIT methodProperties.json
Dale Henrichs-3 wrote My mail may have been a bit harsh, so please read my reply to Peter ... where I think I take a bit more positive tack:) We are beyond politeness, my friend... Not our first rodeo :) Dale Henrichs-3 wrote I am really pressed for time so I don't have the luxury to blue sky ideas ... I understand. I was not suggesting anyone do anything. Also, I agree that methods seem to be the proper level for SCM versioning as they are in the Smalltalk image. I was simply asking, in light of the appearance that the merge driver could seemingly ignore the changes to certain files while still committing them with Git, if it would be feasible to add read-only one-class-per files for viewing on GitHub. This is more of a sanity check to see if I understood what the merge driver makes possible. - Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818323.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Metacello GIT methodProperties.json
Le 08/04/2015 13:23, Sean P. DeNigris a écrit : Dale Henrichs-3 wrote My mail may have been a bit harsh, so please read my reply to Peter ... where I think I take a bit more positive tack:) We are beyond politeness, my friend... Not our first rodeo :) Dale Henrichs-3 wrote I am really pressed for time so I don't have the luxury to blue sky ideas ... I understand. I was not suggesting anyone do anything. Also, I agree that methods seem to be the proper level for SCM versioning as they are in the Smalltalk image. I was simply asking, in light of the appearance that the merge driver could seemingly ignore the changes to certain files while still committing them with Git, if it would be feasible to add read-only one-class-per files for viewing on GitHub. This is more of a sanity check to see if I understood what the merge driver makes possible. The merge driver seemingly ignoring the changes to certain files while still committing? No, doesn't work that way. The merge driver never commits. Unless you mean that, in case of conflicts on merging that file, that the merge driver should be disregarding the conflicts and choose one version over another... Not sure to see how that would work. Remember that the merge driver is only called by git merge. Nothing else. Adding a description file would enter it into the git and make it tracked as are all other files. And adding a file is really not a big deal. Thierry - Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818323.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Spec with dynamic tabs
ok, I put it on my list. Hartmut Am 07.04.15 um 21:14 schrieb Peter Uhnák: Can you add an issue for Pharo 5 so it doesn't get lost? Currently a lot of effort is focused on Pharo 4 release (this week-ish), so nobody might have time to look at this now. Peter On Thu, Apr 2, 2015 at 5:16 PM, Hartmut krasem...@acm.org mailto:krasem...@acm.org wrote: Hi to all, I'm working with Spec and appreciate the modularity a lot. However, I had some difficulties to discover, how I can have a dynamic widget in a tab. Plugging together the TabsExample and the DynamicWidgetChange didn't work either. In the end I discovered the flaw: - In DynamicWidgetChangechange the last line from self openWithSpec to self buildWithSpec . The DynamicWidgetChange example works as before. But now also the following works (I propose to enhance the example): - Add a method dynamicTab | tab | tab := self newTab. tab label: 'Dynamic'; icon: Smalltalk ui icons nautilusIcon; model: (DynamicWidgetChange new). ^ tab to DynamicWidgetChange. - add a line addTab: self dynamicTab to DynamicWidgetChangepopulateManager Now you can dynamically change the widgets in the fourth tab. Cheers, Hartmut -- Hartmut Krasemann Königsberger Str. 41 c D 22869 Schenefeld Tel. 040.8307097 Mobil 0171.6451283 krasem...@acm.org smime.p7s Description: S/MIME Cryptographic Signature
Re: [Pharo-users] Metacello GIT methodProperties.json
Excerpts from Thierry Goubier's message of 2015-04-08 10:11:44 +0200: As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included). Well, as I said elsewhere, Smalltalk doesn't work like that: code has to be lived in the image for most tools to work properly... it doesn't really have an editor of file mindset, but an object inspector mindset. the interesting thing is that i don't think git is the problem here. a git repo does not need to have a working tree. smalltalk git tools could read the code directly from git using git-fast-export and write them with git-fast-import the effect would be that the working tree is now only in the smalltalk image, and git would be a pure storage of history. any use of external tools on the repo would happen on a clone and be pushed into the repo that smalltalk uses. that would however be a complete break with filetree. (it could still create compatible structures, it just could not use its code to read and write) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.secaudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.orgrealss.com unix sysadmin Martin Bähr working in chinahttp://societyserver.org/mbaehr/
Re: [Pharo-users] Metacello GIT methodProperties.json
2015-04-08 9:19 GMT+02:00 Martin Bähr mba...@email.archlab.tuwien.ac.at: Excerpts from Peter Uhnák's message of 2015-04-08 08:47:15 +0200: I thnk that rather than focus on the disk format which I hardly ever actually look at i think the disk format is crucial for interoperability with other tools, such as github webinterface, or external editors to work on things like pictures or data. (which is not yet supported (i have an idea how support could look like though)) Open subject... I think there are a few ideas floating around, and maybe a need to see a vision around that. i don't mind file-per-method though, it helps to make the diff-stat more readable, showing which methods have been changed, added or removed... ... that folks should be looking at tools support (like Thierry) ... this is where the real work needs to happen ... good tools can hide the disk fomat completely so why does the disk format matter ... I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. except for displaying the history graph. can't beat gitk or other gui tools for that. having a smalltalk version of that graph would really be great! +1 I saw Martin Dias tools for Epicea during PharoDays, and he has that visualisation in his history browser. I wanted to reuse it, but for now I'm more like chasing bugs and coping with the increased use for gitfiletree. As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). can't you already do that, except that you need to manually update the image by loading/adopting the current state from the repo? There is a bit more behind that. At the moment, if you reopen / refresh a repository inspector, you'll get that update. If you browse from the repository, you'll get a 'original' style browser on the stored code, but dead (can't edit). A vision would be to have normal editing over the repository -- then we could have repository state tracking (and reuse the IDE browser code instead of cloning it inside MC). But there is a conflict with smalltalk vision of live coding: you need a far deeper connection of the repository and the Pharo image, and this is clearly not how CMS are designed... git and fossil and the likes are managing dead files, which is a concept which is clearly older than the beginnings of Smalltalk, and it shows. For me, anything clearly Smalltalk-ish in that approach would require a close integration of the image and a versionning Object persistent storage (which would be smalltalk-only in access to, for example, guarantee syntax correctness). Thierry greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.secaudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
Re: [Pharo-users] Eating your own dog food (Site/Blog)
What you are after? A static site generator or a dynamic engine? Btw. what do you use to render pillar inside the image to something readable? Norbert Am 08.04.2015 um 08:32 schrieb stepharo steph...@free.fr: I started to work on using pillar to do that but nothing ready for people to use. I will work on it at Lviv or during my vacations just after. I want to use it for my website. Right now parts of it are automatically generated from Pharo. Stef Le 7/4/15 10:56, Yuriy Tymchuk a écrit : Oh, I knew that there was a discussion about that, but couldn’t find where. Still, is anybody else using Marina except for Pharo website? Uko On 07 Apr 2015, at 10:45, Damien Cassou damien.cas...@gmail.com wrote: Yuriy Tymchuk yuriy.tymc...@me.com writes: if I want to create a site/blog in pharo… What do I use? I know that there is Pier, but when you check its webpage, the last update is in 2011. Pharo website is built with Marina, but when I check the repo, the last commit was done by me and it was 2 month ago. Will Marina continue to evolve? And is anyone else using Marina? http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615.html -- 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] Metacello GIT methodProperties.json
Excerpts from Peter Uhnák's message of 2015-04-08 08:47:15 +0200: I thnk that rather than focus on the disk format which I hardly ever actually look at i think the disk format is crucial for interoperability with other tools, such as github webinterface, or external editors to work on things like pictures or data. (which is not yet supported (i have an idea how support could look like though)) i don't mind file-per-method though, it helps to make the diff-stat more readable, showing which methods have been changed, added or removed... ... that folks should be looking at tools support (like Thierry) ... this is where the real work needs to happen ... good tools can hide the disk fomat completely so why does the disk format matter ... I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. except for displaying the history graph. can't beat gitk or other gui tools for that. having a smalltalk version of that graph would really be great! As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). can't you already do that, except that you need to manually update the image by loading/adopting the current state from the repo? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.secaudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.orgrealss.com unix sysadmin Martin Bähr working in chinahttp://societyserver.org/mbaehr/
Re: [Pharo-users] Metacello GIT methodProperties.json
2015-04-08 8:47 GMT+02:00 Peter Uhnák i.uh...@gmail.com: I thnk that rather than focus on the disk format which I hardly ever actually look at ... that folks should be looking at tools support (like Thierry) ... this is where the real work needs to happen ... good tools can hide the disk fomat completely so why does the disk format matter ... I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. Agreed and this is in that spirit I did GitFileTree. Dale went a bit further and even integrated the git command line access inside smalltalk via CommandShell... so that you get the best of both worlds without leaving your beloved Smalltalk :) As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included). Well, as I said elsewhere, Smalltalk doesn't work like that: code has to be lived in the image for most tools to work properly... it doesn't really have an editor of file mindset, but an object inspector mindset. What we're looking at in another thread is how to emulate that live object approach over dead files, and, thinking of it, I'm not sure we will succeed well. In short, what you want may never work properly because it is not how it should be conceptualized. But to bottom line this thread (for me at least, because I'm getting lost): 1. methodProperties.json provide compatibility for FileTree, so I don't want to get rid of it (for now) 2. the large amount of file changes is probably a bug (I'll try to be more observant about the commits in the future and hopefully some pattern will emerge.) 3. I shouldn't want to break things for now at least 4. more people are starting to work on Git 5. I need to learn about FileTree at some point if I want to contribute and experiment with (my) ideas (which won't be soon as I'm preparing for my finals) Please ask around for 5. It is valuable to have to expose what we already know. Thierry Thanks for all your answers. Peter On Wed, Apr 8, 2015 at 7:24 AM, Thierry Goubier thierry.goub...@gmail.com wrote: Le 08/04/2015 02:05, Dale Henrichs a écrit : Peter, That looks like a bug in the FileTree writer ... wiht one method change there should have been only one method property file change ... Yes, I'd agree. This is surprising. Unless you had been loading that package via another repository / another version / another branch before in the same image? MCMethodDefinition has a cache which consider equals methods with different timestamps, and, in that case, it would carry the timestamps of the previous version, and writing those upon save instead of the originals. Peter and Sean, If you are interested in contributing code/bugfixes to FileTree, I will welcome pull requests ... As I have mentioned in several posts today, I do not have the time to fiddle with changes to the FileTree format myself, but I welcome contributions. Damien has started work on an updated version of the FileTree format[2]. I have threatened in the past to add an option to a repository that would eliminate the need to store monticello meta data ... Damien is working on starting from scratch on the new format, because the current implementation supports 4-5 different FileTree formats. Damien's work could be leveraged to add an optional Monticello meta data option to FileTree and if your SCM (like git) gives you per method history with the proper tools you can leverage that information.. I would say this could be a reasonable possibility, in that you could have two modes of compatibility: - Complete filetree compatibility for gitfiletree: the current situation, with properties and version written to disk. - Partial filetree compatibility, where that metadata isn't written and you rely on gitfiletree to recreate it to export as .mcz. Partial compatibility has two effects, which need to be considered. When using github:// or bitbucket:// urls, filetree will be used and your packages will end up having no version number (except .1?), no author, no timestamps for methods, etc... And the second one is that, if you clone a mcz inside the gitfiletree repository, the mcz ancestry of versions and author timestamps on methods will be lost, which is something you may not want. Thierry As I ranted in another post ... changing the disk format is the easy part ... building and maintaining tools for the 4-5 different Smalltalk dialects is a different matter ... Dale [1] https://github.com/dalehenrich/filetree/issues [2]
Re: [Pharo-users] Eating your own dog food (Site/Blog)
There is a plan to have pillar rendering with TextModel. I don't think it will support the full pillar syntax. Le 8 avr. 2015 à 11:16, Norbert Hartl a écrit : What you are after? A static site generator or a dynamic engine? Btw. what do you use to render pillar inside the image to something readable? Norbert Am 08.04.2015 um 08:32 schrieb stepharo steph...@free.fr: I started to work on using pillar to do that but nothing ready for people to use. I will work on it at Lviv or during my vacations just after. I want to use it for my website. Right now parts of it are automatically generated from Pharo. Stef Le 7/4/15 10:56, Yuriy Tymchuk a écrit : Oh, I knew that there was a discussion about that, but couldn’t find where. Still, is anybody else using Marina except for Pharo website? Uko On 07 Apr 2015, at 10:45, Damien Cassou damien.cas...@gmail.com wrote: Yuriy Tymchuk yuriy.tymc...@me.com writes: if I want to create a site/blog in pharo… What do I use? I know that there is Pier, but when you check its webpage, the last update is in 2011. Pharo website is built with Marina, but when I check the repo, the last commit was done by me and it was 2 month ago. Will Marina continue to evolve? And is anyone else using Marina? http://forum.world.st/Any-framework-to-create-a-blog-over-seaside-td4810615.html -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. --Winston Churchill smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] String operations
Am 07.04.2015 um 21:31 schrieb Peter Uhnák i.uh...@gmail.com:
'BormParticipant' allButFirst: 4
('BormParticipant' splitOn: 'Borm') last
Thank you both, this will work. :)
In the Moose configuration, there is a CollectionExtensions that allows you
to do this:
'BormParticipant' removePrefix: 'Borm' - 'Participant'.
'BormParticipant' removeSuffix: 'Participant' - 'Borm'
For Pharo 5, we should move these extensions to Pharo.
Isn't it the case that a remove* methods mostly return what has been removed?
Wouldn't be
withoutPrefix:
withoutSuffix:
I guess withoutPrefix: would probably makes more sense.
As well as
allButPrefix:
allButSuffix:
but to me the sound of them is weird.
Norbert
Re: [Pharo-users] GitHub Mirror Workflow
EstebanLM wrote why would you want another format form mirroring? For the case when one is only actually committing to e.g. StHub and then mirroring to GitHub for external visibility, the purpose is not served when a casual observer must drill down several levels to view each method individually. One-class-per-file would be better in that case (where no actual SCM is being done via Git). And if one was using Git, it would still be handy - for the same reason - to have a read-only one-class-per file handy for a quick perusal via GitHub - Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818401.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] GitHub Mirror Workflow
Le 08/04/2015 17:16, Stephan Eggermont a écrit : On 08/04/15 14:38, Esteban Lorenzano wrote: I don’t know your problem… why would you want another format form mirroring? Because with packages the size of Roassal2 you might get rather unhappy on a machine without an SSD. That is a lot of files. Nothing compared to the time needed to load Roassal into the image on that very same machine ;) Thierry
Re: [Pharo-users] Metacello GIT methodProperties.json
On 04/07/2015 10:24 PM, Thierry Goubier wrote: Le 08/04/2015 02:05, Dale Henrichs a écrit : I have threatened in the past to add an option to a repository that would eliminate the need to store monticello meta data ... Damien is working on starting from scratch on the new format, because the current implementation supports 4-5 different FileTree formats. Damien's work could be leveraged to add an optional Monticello meta data option to FileTree and if your SCM (like git) gives you per method history with the proper tools you can leverage that information.. I would say this could be a reasonable possibility, in that you could have two modes of compatibility: - Complete filetree compatibility for gitfiletree: the current situation, with properties and version written to disk. - Partial filetree compatibility, where that metadata isn't written and you rely on gitfiletree to recreate it to export as .mcz. Partial compatibility has two effects, which need to be considered. When using github:// or bitbucket:// urls, filetree will be used and your packages will end up having no version number (except .1?), no author, no timestamps for methods, etc... And the second one is that, if you clone a mcz inside the gitfiletree repository, the mcz ancestry of versions and author timestamps on methods will be lost, which is something you may not want. Yes for Metacello some modifications would need to be made because in a normal mcz universe Metacello will not load a package if the version is older or the same as the one in the image ... and following in the tradition of other Monticello tools the UUID is ignored:( .. I was working with a pure cypress implementation and have written the Metacello code to support these repos ... A better long term solution is to treat these as a CypressPackage or FileTreePackage which has some similarities to Monticello packages ... because faking out Monitcello version numbers and users is not much different than storing the metadata in FileTree ... But someone were to add those options to filetree, I think we could reduce the overall number of hacks:) Dale
Re: [Pharo-users] GitHub Mirror Workflow
I don’t know your problem… why would you want another format form mirroring? Esteban On 08 Apr 2015, at 14:07, Sean P. DeNigris s...@clipperadams.com wrote: Bump :) Sean P. DeNigris wrote for the Mirror on Github use case, I wonder if less granularity wouldn't clearly be more appropriate. I read about using chunk format (not ideal, but perhaps a bit more readable on the mirror) via Gitocello, but loading in Pharo 4.0 broke on the FFI dependency. Any thoughts/suggestions? - Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818339.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] ZnClient: getting more that 19 tweet for data scrapping
Offray - What Sven said is correct. You're not getting an answer about how to violate their Terms of Service because this isn't that kind of place. You've asked 3 times. Once is usually enough. Use the API. For the Soup questions get an inspector on an instance of a SoupTag and start sending it messages it understands and see what you get. Trial and error. Or read the python Soup docs as the commands probably have an equivalent in the Smalltalk library. Most of this programming stuff is reading, doing a little experiment, thinking, then trying again. Sven - I only showed him that SoupTag has a #text message. I'm sure you're busy and had forgotten that the first time he/she asked they stated that they don't want to use the api: http://forum.world.st/Data-scrapping-in-pharo-Extracting-tweets-contents-td4817746.html and provided the download code in an ws.stfx.eu snippet. Hope this helps Paul Sven Van Caekenberghe-2 wrote What Paul showed is basically just a hack. What you probably what is full API access to Twitter, that gives you the real thing, but it is more work and you have to understand all the technical details (unless somebody already did it for you, I don't know - I know that Zinc-SSO can connect to Twitter). https://dev.twitter.com/overview/api On 07 Apr 2015, at 20:23, Offray Vladimir Luna Cárdenas lt; offray@ gt; wrote: Hi, Recently Paul DeBruicker taught me how to refine my code for getting tweets properly. Consider this: =[1] | source anUrl tweet | anUrl := 'https://twitter.com/offrayLC'. source := Soup fromString: (ZnEasy get: anUrl ) contents asString. tweets := (source findAllTagsByClass: 'ProfileTweet-text') collect:[:ea | ea text]. Is working fine, but I would like to get more that 19 tweets, that is what you get by default. There is any way to tell ZnEasy and friends to get more tweets, something similar to what you do when you scroll down into a twitter page? And by the way, I would like to make more sense of the Soup I got in the last line. ea text gives me the tweet contents, but how can I interpret the metadata in the soup? (is a retweet, date of publishing and so on). I could make this for most part of the twitter profile page, but the tweet is kind of elusive, for example how to know that text is the proper message for getting the tweet content? Any pointer to how to make sense of it by myself is greatly appreciated. Cheers, Offray -- View this message in context: http://forum.world.st/ZnClient-getting-more-that-19-tweet-for-data-scrapping-tp4818162p4818361.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Messaging solutions for Pharo
Hi Esteban, did you finally choose MQTT? I'm in the beginning of a project right now where we need to communicate with a bunch of devices and we've considered MQTT, but we don't know whether to use some existing broker like mosquitto or implement it in Pharo. Have you been down this path? Thanks! Bernat. 2014-11-24 11:55 GMT+01:00 Andres Fortier andres.fort...@gmail.com: Hi Stef, thanks! Glad to be doing things in Pharo :) On Sun, Nov 23, 2014 at 9:24 AM, stepharo steph...@free.fr wrote: Hello Andres nice to see you on this list :) Stef Le 19/11/14 19:40, Andres Fortier a écrit : Hi Esteban, Never used either of them, but IIRC there was a Jabber package in Visualworks (JabberXMPP?), although not sure if it provided both client and server. There is also http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but maybe worth a shot considering you only need the server side? HTH, Andrés On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo emaring...@gmail.com wrote: Hi, I'll be needing to add bidirectional messaging to our current Android (Java) application, and as usual I'm expecting to manage the server side of the communication with Pharo. I'm evaluating two alternatives, but I'm in open to other, proven, options. Option 1. WebSockets Open a WebSocket on each device, and push/retrieve messages from each of these, tracking the device id if I need to recreate a new socket (avoiding recreating new sockets in case of connectivity issues, very common). Option 2. MQTT [1] This is basically a mobile oriented MQ, super low footprint on mobile. For what I saw, I could implement the server using an intermediate MQ (RabbitMQ) and use STOMP to connect to it. Option 3. XMPP [3] Provides several features I'll need in the future, like file transfer in addition to regular text messaging. It is very well supported in Android with Smack [4], but I don't know if we have a Pharo server for it, or if somebody ever played with it. By means of simplicity and use load I favor option 1, because I can understand it better, and as everything moves towards web based technologies, I could implement WAMP [5] on top of that in the future. Right now I'd need to have a hundred websockets opened at the same time, which doesn't sound like a heavy load to me, but I certainly don't know. In the future it could be an order of magnitude bigger, and that's why I don't discard more complex solutions like XMPP or MQTT. Regards! [1] http://mqtt.org/ [2] https://github.com/svenvc/docs/blob/master/neo/stamp.md [3] http://xmpp.org/ [4] http://www.igniterealtime.org/projects/smack/ [5] http://wamp.ws/ -- Bernat Romagosa.
Re: [Pharo-users] GitHub Mirror Workflow
probably I kinda cheat, I use the smalltalkhub repo as nothing more than a shell for my github repo. I commit to it only my configuration which in turn loads the code from github . I have done this with Ephestos and Nireas , the configuration browsers entries just load the baseline from my github repos this way people who are not familiar with github can load my code from sthub without installing git or learning git but will getting automagically the latest code from my github repos. Its a win win situation and beats having to maintain multiple repos of the same project :) There is also no need to touch the configuration either so all my work is focus just on the github repo. I recently updated to add info to it for the package catalog. On Wed, Apr 8, 2015 at 3:07 PM, Sean P. DeNigris s...@clipperadams.com wrote: Bump :) Sean P. DeNigris wrote for the Mirror on Github use case, I wonder if less granularity wouldn't clearly be more appropriate. I read about using chunk format (not ideal, but perhaps a bit more readable on the mirror) via Gitocello, but loading in Pharo 4.0 broke on the FFI dependency. Any thoughts/suggestions? - Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818339.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] ZnClient: getting more that 19 tweet for data scrapping
On 08 Apr 2015, at 15:29, Paul DeBruicker pdebr...@gmail.com wrote: Offray - What Sven said is correct. You're not getting an answer about how to violate their Terms of Service because this isn't that kind of place. You've asked 3 times. Once is usually enough. Use the API. For the Soup questions get an inspector on an instance of a SoupTag and start sending it messages it understands and see what you get. Trial and error. Or read the python Soup docs as the commands probably have an equivalent in the Smalltalk library. Most of this programming stuff is reading, doing a little experiment, thinking, then trying again. Sven - I only showed him that SoupTag has a #text message. I'm sure you're busy and had forgotten that the first time he/she asked they stated that they don't want to use the api: http://forum.world.st/Data-scrapping-in-pharo-Extracting-tweets-contents-td4817746.html and provided the download code in an ws.stfx.eu snippet. Paul, I know you understand, we're on the same page. Sven Hope this helps Paul Sven Van Caekenberghe-2 wrote What Paul showed is basically just a hack. What you probably what is full API access to Twitter, that gives you the real thing, but it is more work and you have to understand all the technical details (unless somebody already did it for you, I don't know - I know that Zinc-SSO can connect to Twitter). https://dev.twitter.com/overview/api On 07 Apr 2015, at 20:23, Offray Vladimir Luna Cárdenas lt; offray@ gt; wrote: Hi, Recently Paul DeBruicker taught me how to refine my code for getting tweets properly. Consider this: =[1] | source anUrl tweet | anUrl := 'https://twitter.com/offrayLC'. source := Soup fromString: (ZnEasy get: anUrl ) contents asString. tweets := (source findAllTagsByClass: 'ProfileTweet-text') collect:[:ea | ea text]. Is working fine, but I would like to get more that 19 tweets, that is what you get by default. There is any way to tell ZnEasy and friends to get more tweets, something similar to what you do when you scroll down into a twitter page? And by the way, I would like to make more sense of the Soup I got in the last line. ea text gives me the tweet contents, but how can I interpret the metadata in the soup? (is a retweet, date of publishing and so on). I could make this for most part of the twitter profile page, but the tweet is kind of elusive, for example how to know that text is the proper message for getting the tweet content? Any pointer to how to make sense of it by myself is greatly appreciated. Cheers, Offray -- View this message in context: http://forum.world.st/ZnClient-getting-more-that-19-tweet-for-data-scrapping-tp4818162p4818361.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] GitHub Mirror Workflow
On 08/04/15 14:38, Esteban Lorenzano wrote: I don’t know your problem… why would you want another format form mirroring? Because with packages the size of Roassal2 you might get rather unhappy on a machine without an SSD. That is a lot of files. Stephan
Re: [Pharo-users] Messaging solutions for Pharo
Hi Bernat, I did some with MQTT in Java/Android and JavaScript with Paho, but never used it with Pharo nor in any of our products. Regards! Esteban A. Maringolo 2015-04-08 10:55 GMT-03:00 Bernat Romagosa tibabenfortlapala...@gmail.com: Hi Esteban, did you finally choose MQTT? I'm in the beginning of a project right now where we need to communicate with a bunch of devices and we've considered MQTT, but we don't know whether to use some existing broker like mosquitto or implement it in Pharo. Have you been down this path? Thanks! Bernat. 2014-11-24 11:55 GMT+01:00 Andres Fortier andres.fort...@gmail.com: Hi Stef, thanks! Glad to be doing things in Pharo :) On Sun, Nov 23, 2014 at 9:24 AM, stepharo steph...@free.fr wrote: Hello Andres nice to see you on this list :) Stef Le 19/11/14 19:40, Andres Fortier a écrit : Hi Esteban, Never used either of them, but IIRC there was a Jabber package in Visualworks (JabberXMPP?), although not sure if it provided both client and server. There is also http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but maybe worth a shot considering you only need the server side? HTH, Andrés On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo emaring...@gmail.com wrote: Hi, I'll be needing to add bidirectional messaging to our current Android (Java) application, and as usual I'm expecting to manage the server side of the communication with Pharo. I'm evaluating two alternatives, but I'm in open to other, proven, options. Option 1. WebSockets Open a WebSocket on each device, and push/retrieve messages from each of these, tracking the device id if I need to recreate a new socket (avoiding recreating new sockets in case of connectivity issues, very common). Option 2. MQTT [1] This is basically a mobile oriented MQ, super low footprint on mobile. For what I saw, I could implement the server using an intermediate MQ (RabbitMQ) and use STOMP to connect to it. Option 3. XMPP [3] Provides several features I'll need in the future, like file transfer in addition to regular text messaging. It is very well supported in Android with Smack [4], but I don't know if we have a Pharo server for it, or if somebody ever played with it. By means of simplicity and use load I favor option 1, because I can understand it better, and as everything moves towards web based technologies, I could implement WAMP [5] on top of that in the future. Right now I'd need to have a hundred websockets opened at the same time, which doesn't sound like a heavy load to me, but I certainly don't know. In the future it could be an order of magnitude bigger, and that's why I don't discard more complex solutions like XMPP or MQTT. Regards! [1] http://mqtt.org/ [2] https://github.com/svenvc/docs/blob/master/neo/stamp.md [3] http://xmpp.org/ [4] http://www.igniterealtime.org/projects/smack/ [5] http://wamp.ws/ -- Bernat Romagosa.
Re: [Pharo-users] class variable accessor naming
True, I already found few examples of accessors to class variables, but I like to be sure when I use it for the first time. Thank you. Jan Christian Caldeiro wrote Class variables should be written with Uppercase (but there are some classes in Pharo that don't follow this convention). Class methods (accessors in this case) are written in lowercase. Again, you can find several samples in Pharo. Thanks Christian On Tue, Apr 7, 2015 at 1:54 PM, Jan B. lt; bliznjan@.cvut gt; wrote: Hello Class variable names should start with capital letter (as I just found out), like RecentProjects. We have a getter to it. Should such accessor method be named recentProjects or RecentProjects? ... class#(r/R)ecentProjects ^ RecentProjects Jan -- View this message in context: http://forum.world.st/class-variable-accessor-naming-tp4818137.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/class-variable-accessor-naming-tp4818137p4818431.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] ZnClient: getting more that 19 tweet for data scrapping
Hi Paul and Sven, I will try Twitter API if is necessary, but I'm not trying to get support here on how to violate Twitter ToS. I'm pretty aware of them, but surely there are exceptions. The mail I shared with you (the one Paul point to) about why I would like to not use API but instead use scrapping doesn't go in details, it just said that it was because people who have not a twitter account or signed the ToS should be able to get some twitter info. That special kind of info is the one regarding public political/politicians discourse and my idea to scrap *public* and *specific* data from twitter happens in the context of a project for citizen oversight of political issues empowered by ICT. The project is discussed on detail here: https://www.newschallenge.org/challenge/elections/entries/datapolis-data-narratives-visualizations-for-citizen-oversight-of-politicians-discourses-and-public-contracts-in-social-media-and-the-web So, for the moment, I will get properly account permissions for getting twitter data, but my conviction for the long term is that public political discourse (among others), even the one that circulates on private networks like Twitter or Facebook, should be under Constitutional Terms (like free speech and wide political participation) and not under the restricted ones of Twitter or Facebook. This is a sensible issue and surely needs more talk, may be on another time, but I will follow your advice and extract data from Twitter API and come here with questions about it. Thanks for all your help and support, Offray El 08/04/15 a las 08:29, Paul DeBruicker escribió: Offray - What Sven said is correct. You're not getting an answer about how to violate their Terms of Service because this isn't that kind of place. You've asked 3 times. Once is usually enough. Use the API. For the Soup questions get an inspector on an instance of a SoupTag and start sending it messages it understands and see what you get. Trial and error. Or read the python Soup docs as the commands probably have an equivalent in the Smalltalk library. Most of this programming stuff is reading, doing a little experiment, thinking, then trying again. Sven - I only showed him that SoupTag has a #text message. I'm sure you're busy and had forgotten that the first time he/she asked they stated that they don't want to use the api: http://forum.world.st/Data-scrapping-in-pharo-Extracting-tweets-contents-td4817746.html and provided the download code in an ws.stfx.eu snippet. Hope this helps Paul Sven Van Caekenberghe-2 wrote What Paul showed is basically just a hack. What you probably what is full API access to Twitter, that gives you the real thing, but it is more work and you have to understand all the technical details (unless somebody already did it for you, I don't know - I know that Zinc-SSO can connect to Twitter). https://dev.twitter.com/overview/api On 07 Apr 2015, at 20:23, Offray Vladimir Luna Cárdenas lt; offray@ gt; wrote: Hi, Recently Paul DeBruicker taught me how to refine my code for getting tweets properly. Consider this: =[1] | source anUrl tweet | anUrl := 'https://twitter.com/offrayLC'. source := Soup fromString: (ZnEasy get: anUrl ) contents asString. tweets := (source findAllTagsByClass: 'ProfileTweet-text') collect:[:ea | ea text]. Is working fine, but I would like to get more that 19 tweets, that is what you get by default. There is any way to tell ZnEasy and friends to get more tweets, something similar to what you do when you scroll down into a twitter page? And by the way, I would like to make more sense of the Soup I got in the last line. ea text gives me the tweet contents, but how can I interpret the metadata in the soup? (is a retweet, date of publishing and so on). I could make this for most part of the twitter profile page, but the tweet is kind of elusive, for example how to know that text is the proper message for getting the tweet content? Any pointer to how to make sense of it by myself is greatly appreciated. Cheers, Offray -- View this message in context: http://forum.world.st/ZnClient-getting-more-that-19-tweet-for-data-scrapping-tp4818162p4818361.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Metacello GIT methodProperties.json
Hi Dale, Le 08/04/2015 19:30, Dale Henrichs a écrit : On 04/07/2015 10:24 PM, Thierry Goubier wrote: Le 08/04/2015 02:05, Dale Henrichs a écrit : I have threatened in the past to add an option to a repository that would eliminate the need to store monticello meta data ... Damien is working on starting from scratch on the new format, because the current implementation supports 4-5 different FileTree formats. Damien's work could be leveraged to add an optional Monticello meta data option to FileTree and if your SCM (like git) gives you per method history with the proper tools you can leverage that information.. I would say this could be a reasonable possibility, in that you could have two modes of compatibility: - Complete filetree compatibility for gitfiletree: the current situation, with properties and version written to disk. - Partial filetree compatibility, where that metadata isn't written and you rely on gitfiletree to recreate it to export as .mcz. Partial compatibility has two effects, which need to be considered. When using github:// or bitbucket:// urls, filetree will be used and your packages will end up having no version number (except .1?), no author, no timestamps for methods, etc... And the second one is that, if you clone a mcz inside the gitfiletree repository, the mcz ancestry of versions and author timestamps on methods will be lost, which is something you may not want. Yes for Metacello some modifications would need to be made because in a normal mcz universe Metacello will not load a package if the version is older or the same as the one in the image ... and following in the tradition of other Monticello tools the UUID is ignored:( .. I was working with a pure cypress implementation and have written the Metacello code to support these repos ... Ok. Yes, the version number handling is delicate; even the one used by gitfiletree feels unsatisfying, even if it allows Metacello/Monticello to work as usual. A better long term solution is to treat these as a CypressPackage or FileTreePackage which has some similarities to Monticello packages ... because faking out Monitcello version numbers and users is not much different than storing the metadata in FileTree ... Not sure I understand. I know where the Cypress/FileTree code handles the lack of metadata when reading, that's all :) But someone were to add those options to filetree, I think we could reduce the overall number of hacks:) Another solution I'd see possible is a reduced metadata format, where just the version number of the current package is stored and retrieved (i.e. a version file without ancestry). It would allow FileTree and Metacello to work exactly as usual. And, maybe, I could even unify the UUIDs? There are things in Monticello which needs a rethink to better adapt to SCMs like git (or Fossil: it's so similar to git :) ) while keeping more or less the same appearance: branches, hashes, tags and semantic versionning. But I don't see yet how to handle that or to propose anything. I know that it would be great to reduce the cognitive distance between MC version and history handling, and the same as seen from Metacello baselines and configurations. Branches + baselines are doing a lot to simplify, but MC stuff is unaware of that. And MC should delegate merging to the underlying repository, as well. Thierry
Re: [Pharo-users] Metacello GIT methodProperties.json
On 04/07/2015 11:47 PM, Peter Uhnák wrote: I thnk that rather than focus on the disk format which I hardly ever actually look at ... that folks should be looking at tools support (like Thierry) ... this is where the real work needs to happen ... good tools can hide the disk fomat completely so why does the disk format matter ... I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time. I understand and that is a tension point for FileTree ... the source _is_ on disk and you do use the GitHub tools (or any other git tools independent of those in Smalltalk) that give you a picture of everything that changed including the ugly meta data ... I flip around and use vi at times to edit a method and of course the github tools for pull requests. But then I use the tODE tools for working with git as well ... but as you recognize, the monticello meta data is there for compatibility and righ now at least compatibility is a good thing ... As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included). But to bottom line this thread (for me at least, because I'm getting lost): 1. methodProperties.json provide compatibility for FileTree, so I don't want to get rid of it (for now) 2. the large amount of file changes is probably a bug (I'll try to be more observant about the commits in the future and hopefully some pattern will emerge.) 3. I shouldn't want to break things for now at least 4. more people are starting to work on Git 5. I need to learn about FileTree at some point if I want to contribute and experiment with (my) ideas (which won't be soon as I'm preparing for my finals) All very good points Dale
