Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex
someone did not watch my video tutorial about github ;D go to your github repo front page on the right side you will see an icon labeled settings click on it and the first setting will you see is how to rename the repo. On Sun, Nov 30, 2014 at 9:51 PM, stepharo steph...@free.fr wrote: great now I can compile :) About your question about moving PharoWebStack should be renamed PharoWeb: a Tutorial EntreprisePharo should be renamed PharoWebStack But I do not know how to do that on github. Stef Le 29/11/14 23:22, Luc Fabresse a écrit : now I can compile. I've pushed some fixes on github, we will see if it now breaks for other ;-) @Stef: $ luatex -v This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_3) (rev 4971) do a macport update if you do not have this version. $ sudo port selfupdate $ sudo port update outdated Then, you should be able to compile the latest version on github. Cheers, #Luc 2014-11-29 9:23 GMT+01:00 Luc Fabresse luc.fabre...@gmail.com: can one of you just give me the result of: luatex -v that works compiling the chapter. then, I will investigate. #Luc 2014-11-29 8:55 GMT+01:00 stepharo steph...@free.fr: The problem is not related to that. To display the full encoding the guys here (damien * damien) only found luaTex working. But LuaTex does not work well on our machines apparently. Le 29/11/14 02:38, Ben Coman a écrit : kilon alios wrote: have you tried MacTex ? https://tug.org/mactex/ its what I use with my iMac and so far has been working for me without any issues. I also ended up using MaxTex fairly easily. (I can't remember which other one originally tried that had some issues.) cheers -ben On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse luc.fabre...@gmail.com mailto:luc.fabre...@gmail.com wrote: Hi All, I cannot compile the latest version in SquareBracketAssociates/EnterprisePharo.git My problem is that the FiraSans cannot be found. But in common.tex, the font path is correctly set up and the font is there. So on CI which version of luatex is used? I did not find it in the Jenkins log. I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_1) (rev 4971) Cheers, #Luc
Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex
oh my bad, I had it in one of the early drafts of the video tutorial (had to do several times to cut it down to 10 minutes) but I forgot to include it. Anyway this is how you do it. On Mon, Dec 1, 2014 at 10:33 AM, kilon alios kilon.al...@gmail.com wrote: someone did not watch my video tutorial about github ;D go to your github repo front page on the right side you will see an icon labeled settings click on it and the first setting will you see is how to rename the repo. On Sun, Nov 30, 2014 at 9:51 PM, stepharo steph...@free.fr wrote: great now I can compile :) About your question about moving PharoWebStack should be renamed PharoWeb: a Tutorial EntreprisePharo should be renamed PharoWebStack But I do not know how to do that on github. Stef Le 29/11/14 23:22, Luc Fabresse a écrit : now I can compile. I've pushed some fixes on github, we will see if it now breaks for other ;-) @Stef: $ luatex -v This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_3) (rev 4971) do a macport update if you do not have this version. $ sudo port selfupdate $ sudo port update outdated Then, you should be able to compile the latest version on github. Cheers, #Luc 2014-11-29 9:23 GMT+01:00 Luc Fabresse luc.fabre...@gmail.com: can one of you just give me the result of: luatex -v that works compiling the chapter. then, I will investigate. #Luc 2014-11-29 8:55 GMT+01:00 stepharo steph...@free.fr: The problem is not related to that. To display the full encoding the guys here (damien * damien) only found luaTex working. But LuaTex does not work well on our machines apparently. Le 29/11/14 02:38, Ben Coman a écrit : kilon alios wrote: have you tried MacTex ? https://tug.org/mactex/ its what I use with my iMac and so far has been working for me without any issues. I also ended up using MaxTex fairly easily. (I can't remember which other one originally tried that had some issues.) cheers -ben On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse luc.fabre...@gmail.com mailto:luc.fabre...@gmail.com wrote: Hi All, I cannot compile the latest version in SquareBracketAssociates/EnterprisePharo.git My problem is that the FiraSans cannot be found. But in common.tex, the font path is correctly set up and the font is there. So on CI which version of luatex is used? I did not find it in the Jenkins log. I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_1) (rev 4971) Cheers, #Luc
Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex
2014-12-01 9:45 GMT+01:00 kilon alios kilon.al...@gmail.com: oh my bad, I had it in one of the early drafts of the video tutorial (had to do several times to cut it down to 10 minutes) ;-) but I forgot to include it. Anyway this is how you do it. Thx Kilon Luc On Mon, Dec 1, 2014 at 10:33 AM, kilon alios kilon.al...@gmail.com wrote: someone did not watch my video tutorial about github ;D go to your github repo front page on the right side you will see an icon labeled settings click on it and the first setting will you see is how to rename the repo. On Sun, Nov 30, 2014 at 9:51 PM, stepharo steph...@free.fr wrote: great now I can compile :) About your question about moving PharoWebStack should be renamed PharoWeb: a Tutorial EntreprisePharo should be renamed PharoWebStack But I do not know how to do that on github. Stef Le 29/11/14 23:22, Luc Fabresse a écrit : now I can compile. I've pushed some fixes on github, we will see if it now breaks for other ;-) @Stef: $ luatex -v This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_3) (rev 4971) do a macport update if you do not have this version. $ sudo port selfupdate $ sudo port update outdated Then, you should be able to compile the latest version on github. Cheers, #Luc 2014-11-29 9:23 GMT+01:00 Luc Fabresse luc.fabre...@gmail.com: can one of you just give me the result of: luatex -v that works compiling the chapter. then, I will investigate. #Luc 2014-11-29 8:55 GMT+01:00 stepharo steph...@free.fr: The problem is not related to that. To display the full encoding the guys here (damien * damien) only found luaTex working. But LuaTex does not work well on our machines apparently. Le 29/11/14 02:38, Ben Coman a écrit : kilon alios wrote: have you tried MacTex ? https://tug.org/mactex/ its what I use with my iMac and so far has been working for me without any issues. I also ended up using MaxTex fairly easily. (I can't remember which other one originally tried that had some issues.) cheers -ben On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse luc.fabre...@gmail.com mailto:luc.fabre...@gmail.com wrote: Hi All, I cannot compile the latest version in SquareBracketAssociates/EnterprisePharo.git My problem is that the FiraSans cannot be found. But in common.tex, the font path is correctly set up and the font is there. So on CI which version of luatex is used? I did not find it in the Jenkins log. I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_1) (rev 4971) Cheers, #Luc
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
Thank you Kilon, Jannik 2014-11-27 11:53 GMT+01:00 kilon alios kilon.al...@gmail.com: You dont need anything installed to work with git , apart from git itself. The workflow is the same as with smalltalkhub + the standard workflow of git. I am using filteree which is already included with Pharo. These are the steps from absolute scratch 1) Download git and install it 2) Create an account in Github 3) add a repository in github 4) open the terminal (git in windows comes with its own terminal, macos and linux have own terminals) you can also optionally create a folder for putting all your git projects inside 5) config git using the git config command to add your email 6) copy the adress of your github repo , its on the right side of your central page of your github repo it has a button next to it to copy it 7) paste the adress after the git clone command and hit enter to clone the repo to your local drive 8) Go to pharo , open monticello and add for you new package a repo , choose gitfilete 9) filetree with open a file browser dialog, navigate to the folder you clone your gihub repo and press open 10) click save as usual to save code , add a commit message, I also copy the commit message to add it also in the git commit 11) go back to the terminal and cd to your git folder of your project 12) I use git status to see which files the filetree has created , Packages have their own folders and so does each class, with also a folder for instance and class side. Each methods has its own file, additional files exist for metadata. 13) git add the package folders. A simple git add of a folder will add all subfolders and files included in the folder. 14) git commit -am paste here the copied message from monticello, or add your own commit message 15) git push If you exclude step (8) and (9) the rest is normal git workflow Thats for setting up from there on for committing you will repeat only steps (10) - (15). There is also gitfiletree that automates this manual process but I like being in control to what is commited to my git repo. Gitfiletree has a chapter in Pharo For the Enterprise book. Github has extensive documentation for git and github. Git website also has documentation that is easy to follow and expose how powerful git really is. Its actually very simple and easy to do. On Thu, Nov 27, 2014 at 12:32 PM, jannik laval jannik.la...@gmail.com wrote: Hi Kilon, Do you have any documentation on how to use github in Pharo ? What should I install, how to use it ? Thank you. Jannik 2014-11-27 11:29 GMT+01:00 kilon alios kilon.al...@gmail.com: My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages. With the use of Baseline you dont even need git installed in your system to install any Pharo project that use git which is a feature I have not seen in other languages. It should be also relative simple to extend ConfigurationBrowser to support github projects via baseline with no need to commit configurations to smalltalkhub. Pharo is already very active in github, many people have ported their projects there including me. Maybe StHub should support also being a portal to github , or uses github as its backend though I have no clue how much work that would involve. Personally I have completely abandoned smaltlalkhub for github because my experience was really bad and I was already very familiar with github. On Thu, Nov 27, 2014 at 12:14 PM, Noury Bouraqadi bouraq...@gmail.com wrote: SmalltalkHub is slow, so don’t click too fast :-( While I’m grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We don’t have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... It’s better to use some mainstream platform such as github. We’ll we have support for it in Pharo 4? It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. Noury -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/ -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
Hello, From my experience point of view with SmalltlakHub, I found this tool remarkably stable, useful, feature complete and quite well integrated with Monticello. I want to say thank you guys for the energy you spend to keep it running. Hilaire Le 27/11/2014 11:14, Noury Bouraqadi a écrit : SmalltalkHub is slow, so don’t click too fast :-( While I’m grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We don’t have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... It’s better to use some mainstream platform such as github. We’ll we have support for it in Pharo 4? It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. Noury -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
Le 27/11/2014 11:29, kilon alios a écrit : My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages. With git, don't you lost the capability to browse the history of changes in your code? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex
On 01 Dec 2014, at 09:51, Luc Fabresse luc.fabre...@gmail.com wrote: someone did not watch my video tutorial about github ;D go to your github repo front page on the right side you will see an icon labeled settings click on it and the first setting will you see is how to rename the repo. On Sun, Nov 30, 2014 at 9:51 PM, stepharo steph...@free.fr mailto:steph...@free.fr wrote: great now I can compile :) About your question about moving PharoWebStack should be renamed PharoWeb: a Tutorial EntreprisePharo should be renamed PharoWebStack But I do not know how to do that on github. it is quite simple: go to the project, go to settings (in the right side), then rename repository. … and of course you will need to do a new clone (with the new name) Esteban Stef Le 29/11/14 23:22, Luc Fabresse a écrit : now I can compile. I've pushed some fixes on github, we will see if it now breaks for other ;-) @Stef: $ luatex -v This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_3) (rev 4971) do a macport update if you do not have this version. $ sudo port selfupdate $ sudo port update outdated Then, you should be able to compile the latest version on github. Cheers, #Luc 2014-11-29 9:23 GMT+01:00 Luc Fabresse luc.fabre...@gmail.com mailto:luc.fabre...@gmail.com: can one of you just give me the result of: luatex -v that works compiling the chapter. then, I will investigate. #Luc 2014-11-29 8:55 GMT+01:00 stepharo steph...@free.fr mailto:steph...@free.fr: The problem is not related to that. To display the full encoding the guys here (damien * damien) only found luaTex working. But LuaTex does not work well on our machines apparently. Le 29/11/14 02:38, Ben Coman a écrit : kilon alios wrote: have you tried MacTex ? https://tug.org/mactex/ https://tug.org/mactex/ its what I use with my iMac and so far has been working for me without any issues. I also ended up using MaxTex fairly easily. (I can't remember which other one originally tried that had some issues.) cheers -ben On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse luc.fabre...@gmail.com mailto:luc.fabre...@gmail.com mailto:luc.fabre...@gmail.com mailto:luc.fabre...@gmail.com wrote: Hi All, I cannot compile the latest version in SquareBracketAssociates/EnterprisePharo.git My problem is that the FiraSans cannot be found. But in common.tex, the font path is correctly set up and the font is there. So on CI which version of luatex is used? I did not find it in the Jenkins log. I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_1) (rev 4971) Cheers, #Luc
Re: [Pharo-dev] tests coverage of minimal Pharo
ignorant question: What is a black listed class? :) On Sun, Nov 30, 2014 at 7:21 PM, Pavel Krivanek pavel.kriva...@gmail.com wrote: Hi, I set the job for tests coverage testing of the mimimal Pharo using Hapao: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2.2-Hapao-Coverage-Test/ To load results you should load ConfigurationOfSUnit and ConfigurationOfKernelTests from Pharo/SystemConfigurations repository into an image with Hapao. Then inspect: FLMaterializer materializeFromFileNamed: 'hapao.fuel'. Do not try to visualise it ;-) Currently blacklisted classes are: Array Association ArrayedCollection Behavior BlockClosure ByteSymbol ByteString ClassDescription CompiledMethod Class Dictionary Hapao2Package HashedCollection IdentityDictionary Integer LookupKey FileStream Magnitude Object ProtoObject Process ProcessLocalVariable ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage SmalltalkImage SequenceableCollection Set Semaphore SmallInteger Symbol String SourceFileArray VirtualMachine OCCompilerTest SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack S2StringNewPlugin S2TestException S2Tester S2TesterClass S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod S2pySenderStubPackage Cheers, -- Pavel
Re: [Pharo-dev] merge conflict (issue validator)
On 29 Nov 2014, at 23:04, Nicolai Hess nicolaih...@web.de wrote: I don't understand this merge conflict in hte issue validation for case 14288 https://pharo.fogbugz.com/default.asp?14288 I can manually load the slice and it does not show any conflicts. I actually looked at it when the same time it failed with the monkye, and I got the same conflicts. I think this is a bug that might be related to MC not getting the right file to diff sometimes from SmalltalkHub. I have put it back to review needed to see if it works now. Marcus
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
Thank's Dale and Esteban for explanation 2014-11-30 18:58 GMT+03:00 Dale Henrichs dale.henri...@gemtalksystems.com: Actually, SS3 and smalltalkhub appeared about the same time. Tobias Pape had been slowly improving the GemStone version of SqueakSource3 and I got tired of waiting 2-3 days for SqueakSource to come back from a crash, so I pushed SS3 up as an Alpha to get something up that was more stable than SqueakSource. About the same time, SmalltalkHub was made available and I didn't want to compete with SmalltalkHub and at the time it seemed to have potential, so I backed off on my plans to go beyond the Alpha release of SS3. There were several sets of known bugs and performance issues ... but it was and still is Alpha and was never intended to go into production. After several months of development, SmalltalkHub had not quite made it to be production ready and Stef asked me to start backing up SS3 so that it could be used for production apps ... I reluctantly agreed, because at the time SqueakSource was very unstable and something was needed ... Unfortunately the time window for me to have time to devote time to SS3 had passed and Tobias was busy with his work as well. And it took longer than originally anticipated for SmalltalkHub to be ready for prime time. Tobias has continued to work on the SqueakSource3 code base and bring it way beyond the Alpha version that is in production. The folks at Hasso Plattner Institute are using Tobias' SqueakSource3 in production for their Smalltalk repos. But it seemed to not be worth the effort to try to compete with SmalltalkHub ... the original intent of SS3 being brought into production was to be a stopgap measure until SmalltalkHub was ready... Today, I am using GitHub for all of my projects ([1], [2], [3], and [4]) so again I just don't have the time to devote to SS3 to incorporate the improvements that Tobias has had (for years now) Neither SqueakSource3 nor SmalltalkHub comes close to the collaborative feature set of GitHub and I personally would rather devote my own time and effort to new Smalltalk projects than trying to duplicate GitHub in Smalltalk. We continue to host SS3, with all of its Alpha warts because is very stable and a number of folks use it on a daily basis... Dale [1] https://github.com/GsDevKit [2] https://github.com/glassdb [3] https://github.com/dalehenrich [4] https://github.com/CampSmalltalk On Sun, Nov 30, 2014 at 4:41 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2014-11-27 18:01 GMT+03:00 Esteban Lorenzano esteba...@gmail.com: btw… historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: “yes, the future it will be git, but until we get there, let’s put sthub online because sqsource cannot handle more projects And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
2014-12-01 11:21 GMT+01:00 Hilaire hila...@drgeo.eu: Le 27/11/2014 11:29, kilon alios a écrit : My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages. With git, don't you lost the capability to browse the history of changes in your code? Not with GitFileTree. You get an as good or even better history (i.e. garanteed merge: its common to see long project histories in mcz with missing versions in history, with sometimes merge failures in Monticello as a consequence). You can also browse changes in subsets: all versions of a method across hundreds of packages versions, you could track all versions of a class, etc... All this is local and synchronized to the remote: you have a complete local history, which makes querying the history a lot easier (than downloading hundreds of mcz(s) from smalltalkhub). It is also convenient to be able to commit properly without an internet connection. A true competitor to Pharo+git is a database-based system with replication / merge. I think the Squeak side has it (I remember Eliot talking about that). Thierry Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
No of course not. That would have been a deal braker. Personally I prefer using Sourcetree to browser history of commits than using the pharo on board tools. Pharo is good on that respect, but sourcetree is better and smartgit I have used in the past. It also has nice visualisation for branches , merges etc. I have not shown these features in my video tutorial as I was planning to show them to a separate tutorial. I would not mind bypassing monticello completely since its usage is unnecessary at least to me with all these git tools that one can download and use for free. The same is true for other IDEs out there , generally people prefer using dedicate tools. Usually dedicate tools are hard to beat this is why I believe modularising Pharo is extremely important as will make integrating external tools way easier. I think however that Roassal can be used to visualise in similar way the history as Sourcetree does. So pharo is not far from it but as always its a matter of someone doing the hard work. On Mon, Dec 1, 2014 at 12:21 PM, Hilaire hila...@drgeo.eu wrote: Le 27/11/2014 11:29, kilon alios a écrit : My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages. With git, don't you lost the capability to browse the history of changes in your code? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
+1 Doru On Mon, Dec 1, 2014 at 11:19 AM, Hilaire hila...@drgeo.eu wrote: Hello, From my experience point of view with SmalltlakHub, I found this tool remarkably stable, useful, feature complete and quite well integrated with Monticello. I want to say thank you guys for the energy you spend to keep it running. Hilaire Le 27/11/2014 11:14, Noury Bouraqadi a écrit : SmalltalkHub is slow, so don’t click too fast :-( While I’m grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We don’t have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... It’s better to use some mainstream platform such as github. We’ll we have support for it in Pharo 4? It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. Noury -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] merge conflict (issue validator)
On 01 Dec 2014, at 11:40, Marcus Denker marcus.den...@inria.fr wrote: On 29 Nov 2014, at 23:04, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: I don't understand this merge conflict in hte issue validation for case 14288 https://pharo.fogbugz.com/default.asp?14288 I can manually load the slice and it does not show any conflicts. I actually looked at it when the same time it failed with the monkye, and I got the same conflicts. I think this is a bug that might be related to MC not getting the right file to diff sometimes from SmalltalkHub. I have put it back to review needed to see if it works now. This time it worked fine, I will integrate it now. Marcus
[Pharo-dev] [pharo-project/pharo-core] 8be654: 40392
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 8be654fa95e7a5c6d96607b7513e3dde8a1ffb74 https://github.com/pharo-project/pharo-core/commit/8be654fa95e7a5c6d96607b7513e3dde8a1ffb74 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-12-01 (Mon, 01 Dec 2014) Changed paths: A Kernel.package/Float.class/class/instance creation/fromIEEE64Bit_.st A Kernel.package/Float.class/instance/printing/binaryLiteralString.st A Kernel.package/Float.class/instance/printing/printBinaryLiteralOn_.st A KernelTests.package/FloatTest.class/instance/tests - printing/testBinaryLiteralString.st A Manifest-Core.package/extension/RBExplicitRequirementMethodsRule/instance/category.st A Nautilus.package/CodeSearchingAcceptor.class/README.md A Nautilus.package/CodeSearchingAcceptor.class/definition.st A Nautilus.package/CodeSearchingAcceptor.class/instance/protocol/accept_notifying_.st A NautilusRefactoring.package/CodeSearchingRule.class/README.md A NautilusRefactoring.package/CodeSearchingRule.class/definition.st A NautilusRefactoring.package/CodeSearchingRule.class/instance/accessing/matcher_.st A NautilusRefactoring.package/CodeSearchingRule.class/instance/accessing/name.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/rewrite code/searchCode.st A NautilusRefactoring.package/extension/NautilusUI/instance/searchCode_.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/README.md A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/definition.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/accessing/name.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/accessing/rationale.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/instance/running/checkClass_.st M SUnit-Core.package/TestCase.class/instance/printing/printOn_.st A SUnit-Core.package/TestCase.class/instance/printing/printTestSelectorDefiningClass_on_.st A SUnit-Core.package/TestCase.class/instance/printing/printTestSelectorOn_.st M SUnit-Tests.package/SUnitTest.class/instance/testing/testFileOutResult.st M SUnit-UI.package/TestRunner.class/instance/browsing/browseSelectedTest_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script392.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40392.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeFloatInspector.class/instance/list/addSpecialFields_.st Log Message: --- 40392 14550 testTraitExplicitRequirementMethodsMustBeImplementedInTheClassOrInASuperclass failing 200 times https://pharo.fogbugz.com/f/cases/14550 14288 Show binary literal for Floats in inspectors https://pharo.fogbugz.com/f/cases/14288 14551 Pharo 4.0: Fix Search Code refactoring menu item in Nautilus https://pharo.fogbugz.com/f/cases/14551 14546 Failed inherited tests should show home class (in TestRunner, like the debugger) https://pharo.fogbugz.com/f/cases/14546 http://files.pharo.org/image/40/40392.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40392 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] tests coverage of minimal Pharo
Hapao works using method wrappers, and do some stuff for every method execution. If Hapao use something you are instrumenting, you are start looping endlessly. So blacklisted classes are classes you are not going to instrument. But, I was trying to understand all the classes you blacklisted, and I don’t understand why you have some tests blacklisted, any reason for them? Cheers, Alejandro On Dec 1, 2014, at 7:57 AM, Guillermo Polito guillermopol...@gmail.com wrote: ignorant question: What is a black listed class? :) On Sun, Nov 30, 2014 at 7:21 PM, Pavel Krivanek pavel.kriva...@gmail.com mailto:pavel.kriva...@gmail.com wrote: Hi, I set the job for tests coverage testing of the mimimal Pharo using Hapao: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2.2-Hapao-Coverage-Test/ https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2.2-Hapao-Coverage-Test/ To load results you should load ConfigurationOfSUnit and ConfigurationOfKernelTests from Pharo/SystemConfigurations repository into an image with Hapao. Then inspect: FLMaterializer materializeFromFileNamed: 'hapao.fuel'. Do not try to visualise it ;-) Currently blacklisted classes are: Array Association ArrayedCollection Behavior BlockClosure ByteSymbol ByteString ClassDescription CompiledMethod Class Dictionary Hapao2Package HashedCollection IdentityDictionary Integer LookupKey FileStream Magnitude Object ProtoObject Process ProcessLocalVariable ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage SmalltalkImage SequenceableCollection Set Semaphore SmallInteger Symbol String SourceFileArray VirtualMachine OCCompilerTest SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack S2StringNewPlugin S2TestException S2Tester S2TesterClass S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod S2pySenderStubPackage Cheers, -- Pavel
Re: [Pharo-dev] merge conflict (issue validator)
2014-12-01 13:39 GMT+01:00 Marcus Denker marcus.den...@inria.fr: On 01 Dec 2014, at 11:40, Marcus Denker marcus.den...@inria.fr wrote: On 29 Nov 2014, at 23:04, Nicolai Hess nicolaih...@web.de wrote: I don't understand this merge conflict in hte issue validation for case 14288 https://pharo.fogbugz.com/default.asp?14288 I can manually load the slice and it does not show any conflicts. I actually looked at it when the same time it failed with the monkye, and I got the same conflicts. I think this is a bug that might be related to MC not getting the right file to diff sometimes from SmalltalkHub. I have put it back to review needed to see if it works now. This time it worked fine, I will integrate it now. Marcus Thank you.
Re: [Pharo-dev] tests coverage of minimal Pharo
Right. Some tests ended with out-of-memory errors or vm crash. One problem was in a trait so I had to put all users of it on the blacklist. Cheers, -- Pavel 2014-12-01 14:21 GMT+01:00 Alejandro Infante alejandroinfant...@gmail.com: Hapao works using method wrappers, and do some stuff for every method execution. If Hapao use something you are instrumenting, you are start looping endlessly. So blacklisted classes are classes you are not going to instrument. But, I was trying to understand all the classes you blacklisted, and I don’t understand why you have some tests blacklisted, any reason for them? Cheers, Alejandro On Dec 1, 2014, at 7:57 AM, Guillermo Polito guillermopol...@gmail.com wrote: ignorant question: What is a black listed class? :) On Sun, Nov 30, 2014 at 7:21 PM, Pavel Krivanek pavel.kriva...@gmail.com wrote: Hi, I set the job for tests coverage testing of the mimimal Pharo using Hapao: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2.2-Hapao-Coverage-Test/ To load results you should load ConfigurationOfSUnit and ConfigurationOfKernelTests from Pharo/SystemConfigurations repository into an image with Hapao. Then inspect: FLMaterializer materializeFromFileNamed: 'hapao.fuel'. Do not try to visualise it ;-) Currently blacklisted classes are: Array Association ArrayedCollection Behavior BlockClosure ByteSymbol ByteString ClassDescription CompiledMethod Class Dictionary Hapao2Package HashedCollection IdentityDictionary Integer LookupKey FileStream Magnitude Object ProtoObject Process ProcessLocalVariable ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage SmalltalkImage SequenceableCollection Set Semaphore SmallInteger Symbol String SourceFileArray VirtualMachine OCCompilerTest SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack S2StringNewPlugin S2TestException S2Tester S2TesterClass S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod S2pySenderStubPackage Cheers, -- Pavel
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
On Mon, Dec 1, 2014 at 7:00 AM, seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: Two commercial installs of a Pharo/Seaside based solution. Some tweets with the #pharo tag. ### What's next, until 2014-12-14 (*): More installs. More deals. Using Mongodb more extensively for one application. Start of a new application module on business dashboarding. Documentation of our system writing using Pillar. CommandLineHandler based tool for console based administration of the system. (*) we'll be expecting results by then ;)
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
Nice ! On 01 Dec 2014, at 15:01, p...@highoctane.be wrote: On Mon, Dec 1, 2014 at 7:00 AM, seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: Two commercial installs of a Pharo/Seaside based solution. Some tweets with the #pharo tag. ### What's next, until 2014-12-14 (*): More installs. More deals. Using Mongodb more extensively for one application. Start of a new application module on business dashboarding. Documentation of our system writing using Pillar. CommandLineHandler based tool for console based administration of the system. (*) we'll be expecting results by then ;)
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
On Mon, Dec 1, 2014 at 7:00 AM, seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: Fixed remaining Moose 5.0 issues. Worked on a project I cannot wait to announce :) ### What's next, until 2014-12-14 (*): Find a way to reliably release Moose. Announce the unannounced project :) Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
El Mon Dec 01 2014 at 3:00:29 AM, seas...@rmod.lille.inria.fr escribió: ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-12-14 (*): - I Attended to a regional BarCamp to talked about OOP, Smalltalk and Pharo. Got very good reception and feedback. One of the attendants even tried Pharo some time ago. The critics were same as usual. - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION Continue to improve our Pharo based applications. Refactoring all the way down.
Re: [Pharo-dev] [Moose-dev] Woden-GT integration
If I remember correctly, Doru told me he worked on it Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Dec 1, 2014, at 5:31 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi everyone, I think that during ESUG Woden was integrated into Toolkit in a way, what you can see a 3D visualization as one of the representations of the view. Is there any additional package that provides this functionality? Uko ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Re: [Pharo-dev] [Moose-dev] Woden-GT integration
And I have to fix a bug that chrashes it. (opening a view twice) 2014-12-01 11:35 GMT-03:00 Alexandre Bergel alexandre.ber...@me.com: If I remember correctly, Doru told me he worked on it Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Dec 1, 2014, at 5:31 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi everyone, I think that during ESUG Woden was integrated into Toolkit in a way, what you can see a 3D visualization as one of the representations of the view. Is there any additional package that provides this functionality? Uko ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
[Pharo-dev] Woden processor occupation and text highlight
Hi, first of all let me know where I can write questions about Woden (because I have not seen a lot of activity around it in any chat). Woden and Roassal3D have a problem that when the 3D window is shown, text highlighting is not working. Usually it’s not a big deal, but Rubric writes white text on white background :). I think a problem like that was already in Roassal2 and maybe someone remembers how to solve that? Uko
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
On 2014-12-01 07:00, seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - Created a Ubuntu 14.04 32 Bit virtual machine to take over the ubuntu ppa updating from Damien Cassou ### What's next, until 2014-12-14 (*): - Switching my scripts back to the pharo-ppa once my packages turn out to be useable - Make myself familiar with the pharo vm generation process - see if there are more pharo vm flavours that could be offered in the ppa
Re: [Pharo-dev] [Moose-dev] Woden-GT integration
There is a GT-InspectorExtensions-Woden package in the GT repository. Doru On Mon, Dec 1, 2014 at 3:39 PM, Ronie Salgado ronies...@gmail.com wrote: And I have to fix a bug that chrashes it. (opening a view twice) 2014-12-01 11:35 GMT-03:00 Alexandre Bergel alexandre.ber...@me.com: If I remember correctly, Doru told me he worked on it Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Dec 1, 2014, at 5:31 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi everyone, I think that during ESUG Woden was integrated into Toolkit in a way, what you can see a 3D visualization as one of the representations of the view. Is there any additional package that provides this functionality? Uko ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Woden processor occupation and text highlight
I think it is fine to keep the discussions either on the Pharo or on the Moose mailing list :). Doru On Mon, Dec 1, 2014 at 3:39 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, first of all let me know where I can write questions about Woden (because I have not seen a lot of activity around it in any chat). Woden and Roassal3D have a problem that when the 3D window is shown, text highlighting is not working. Usually it’s not a big deal, but Rubric writes white text on white background :). I think a problem like that was already in Roassal2 and maybe someone remembers how to solve that? Uko -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] tests coverage of minimal Pharo
Would Hapao benefit from using reflectivity as it's intercession framework instead of using method wrappers? Maybe in such a way it can also instrument classes such as Array, Object... On Mon, Dec 1, 2014 at 2:34 PM, Pavel Krivanek pavel.kriva...@gmail.com wrote: Right. Some tests ended with out-of-memory errors or vm crash. One problem was in a trait so I had to put all users of it on the blacklist. Cheers, -- Pavel 2014-12-01 14:21 GMT+01:00 Alejandro Infante alejandroinfant...@gmail.com : Hapao works using method wrappers, and do some stuff for every method execution. If Hapao use something you are instrumenting, you are start looping endlessly. So blacklisted classes are classes you are not going to instrument. But, I was trying to understand all the classes you blacklisted, and I don’t understand why you have some tests blacklisted, any reason for them? Cheers, Alejandro On Dec 1, 2014, at 7:57 AM, Guillermo Polito guillermopol...@gmail.com wrote: ignorant question: What is a black listed class? :) On Sun, Nov 30, 2014 at 7:21 PM, Pavel Krivanek pavel.kriva...@gmail.com wrote: Hi, I set the job for tests coverage testing of the mimimal Pharo using Hapao: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2.2-Hapao-Coverage-Test/ To load results you should load ConfigurationOfSUnit and ConfigurationOfKernelTests from Pharo/SystemConfigurations repository into an image with Hapao. Then inspect: FLMaterializer materializeFromFileNamed: 'hapao.fuel'. Do not try to visualise it ;-) Currently blacklisted classes are: Array Association ArrayedCollection Behavior BlockClosure ByteSymbol ByteString ClassDescription CompiledMethod Class Dictionary Hapao2Package HashedCollection IdentityDictionary Integer LookupKey FileStream Magnitude Object ProtoObject Process ProcessLocalVariable ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage SmalltalkImage SequenceableCollection Set Semaphore SmallInteger Symbol String SourceFileArray VirtualMachine OCCompilerTest SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack S2StringNewPlugin S2TestException S2Tester S2TesterClass S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod S2pySenderStubPackage Cheers, -- Pavel
Re: [Pharo-dev] tests coverage of minimal Pharo
Would Hapao benefit from using reflectivity as it's intercession framework instead of using method wrappers? Maybe in such a way it can also instrument classes such as Array, Object… May be. But I am wondering whether it will really solve the problem. I guess reflectivity is using the same kind of transformation as we do. In Java, the JVM provides an interface, to which you can connect a debugger. With such interface, you can literally profile anything. Alexandre On Mon, Dec 1, 2014 at 2:34 PM, Pavel Krivanek pavel.kriva...@gmail.com mailto:pavel.kriva...@gmail.com wrote: Right. Some tests ended with out-of-memory errors or vm crash. One problem was in a trait so I had to put all users of it on the blacklist. Cheers, -- Pavel 2014-12-01 14:21 GMT+01:00 Alejandro Infante alejandroinfant...@gmail.com mailto:alejandroinfant...@gmail.com: Hapao works using method wrappers, and do some stuff for every method execution. If Hapao use something you are instrumenting, you are start looping endlessly. So blacklisted classes are classes you are not going to instrument. But, I was trying to understand all the classes you blacklisted, and I don’t understand why you have some tests blacklisted, any reason for them? Cheers, Alejandro On Dec 1, 2014, at 7:57 AM, Guillermo Polito guillermopol...@gmail.com mailto:guillermopol...@gmail.com wrote: ignorant question: What is a black listed class? :) On Sun, Nov 30, 2014 at 7:21 PM, Pavel Krivanek pavel.kriva...@gmail.com mailto:pavel.kriva...@gmail.com wrote: Hi, I set the job for tests coverage testing of the mimimal Pharo using Hapao: https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2.2-Hapao-Coverage-Test/ https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-2.2-Hapao-Coverage-Test/ To load results you should load ConfigurationOfSUnit and ConfigurationOfKernelTests from Pharo/SystemConfigurations repository into an image with Hapao. Then inspect: FLMaterializer materializeFromFileNamed: 'hapao.fuel'. Do not try to visualise it ;-) Currently blacklisted classes are: Array Association ArrayedCollection Behavior BlockClosure ByteSymbol ByteString ClassDescription CompiledMethod Class Dictionary Hapao2Package HashedCollection IdentityDictionary Integer LookupKey FileStream Magnitude Object ProtoObject Process ProcessLocalVariable ProcessorScheduler ProcessSpecificVariable RPackageOrganizer RPackage SmalltalkImage SequenceableCollection Set Semaphore SmallInteger Symbol String SourceFileArray VirtualMachine OCCompilerTest SortedCollectionTest DictionaryTest SetTest ArrayTest SymbolTest BagTest StringTest HeapTest FloatArrayTest OrderedCollectionTest LinkedListTest S2BasicNewStub S2BasicNewStubClass S2BasicNewStubMethod S2BasicNewStubPackage S2BasicNewTest S2C S2CClass S2CMethod S2CPackage S2Class S2ClassPlugin S2Context S2InsertBehaviorPlugin S2Lock S2Method S2MethodPlugin S2Package S2Plugin S2PluginTest S2PointNewPlugin S2Profiler S2ProfilerPlugin S2ProfilerTest S2SenderTest S2SpyStack S2StringNewPlugin S2TestException S2Tester S2TesterClass S2TesterMethod S2TesterPackage S2TesterSpy S2py S2pyA S2pyB S2pyDummyTest S2pySenderStub S2pySenderStubClass S2pySenderStubMethod S2pySenderStubPackage Cheers, -- Pavel
Re: [Pharo-dev] [Moose-dev] Woden processor occupation and text highlight
Woden and Roassal3D have a problem that when the 3D window is shown, text highlighting is not working. Usually it’s not a big deal, but Rubric writes white text on white background :). I think a problem like that was already in Roassal2 and maybe someone remembers how to solve that? It was the case in Roassal2 yes. This happens when the the window was constantly refreshing, thus no time left for the process behind the text hilighting. Maybe there is the same problem. You can have a look at the TRMorph class. Cheers, Alexandre
Re: [Pharo-dev] [Moose-dev] Woden processor occupation and text highlight
It was the case in Roassal2 yes. This happens when the the window was constantly refreshing, That is not a problem of Woden. It has to be constantly refreshing. But it is a problem for Woden-Roassal... I guess, that the problem could be worse if I enabled vsync in the SDL2 backend (it blocks). 2014-12-01 12:09 GMT-03:00 Alexandre Bergel alexandre.ber...@me.com: Woden and Roassal3D have a problem that when the 3D window is shown, text highlighting is not working. Usually it’s not a big deal, but Rubric writes white text on white background :). I think a problem like that was already in Roassal2 and maybe someone remembers how to solve that? It was the case in Roassal2 yes. This happens when the the window was constantly refreshing, thus no time left for the process behind the text hilighting. Maybe there is the same problem. You can have a look at the TRMorph class. Cheers, Alexandre
Re: [Pharo-dev] [Moose-dev] Woden processor occupation and text highlight
On 01 Dec 2014, at 16:14, Ronie Salgado ronies...@gmail.com wrote: It was the case in Roassal2 yes. This happens when the the window was constantly refreshing, That is not a problem of Woden. It has to be constantly refreshing. But it is a problem for Woden-Roassal... I guess, that the problem could be worse if I enabled vsync in the SDL2 backend (it blocks). Ok, but can we make this work better? :) 2014-12-01 12:09 GMT-03:00 Alexandre Bergel alexandre.ber...@me.com mailto:alexandre.ber...@me.com: Woden and Roassal3D have a problem that when the 3D window is shown, text highlighting is not working. Usually it’s not a big deal, but Rubric writes white text on white background :). I think a problem like that was already in Roassal2 and maybe someone remembers how to solve that? It was the case in Roassal2 yes. This happens when the the window was constantly refreshing, thus no time left for the process behind the text hilighting. Maybe there is the same problem. You can have a look at the TRMorph class. Cheers, Alexandre
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
Am 01.12.14 12:34, schrieb kilon alios: No of course not. That would have been a deal braker. Personally I prefer using Sourcetree to browser history of commits than using the pharo on board tools. Pharo is good on that respect, but sourcetree is better Alas Sourcetree is only available for Windows and Mac OSX. Non-portable programs die with their system. Closed source programs die with their company. That's one of the reasons I like Pharo: it's open source and I was able to port the VM to my prefered OS (Ok, NativeBoost is still missing (not working) but the rest is doing fine). Furthermore I really enjoy Squeak's and Pharo ecosystem. The more tools and frameworks are inside the less they depend on the underlying OS. Andreas and smartgit I have used in the past. It also has nice visualisation for branches , merges etc. I have not shown these features in my video tutorial as I was planning to show them to a separate tutorial. I would not mind bypassing monticello completely since its usage is unnecessary at least to me with all these git tools that one can download and use for free. The same is true for other IDEs out there , generally people prefer using dedicate tools. Usually dedicate tools are hard to beat this is why I believe modularising Pharo is extremely important as will make integrating external tools way easier. I think however that Roassal can be used to visualise in similar way the history as Sourcetree does. So pharo is not far from it but as always its a matter of someone doing the hard work. On Mon, Dec 1, 2014 at 12:21 PM, Hilaire hila...@drgeo.eu mailto:hila...@drgeo.eu wrote: Le 27/11/2014 11:29, kilon alios a écrit : My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages. With git, don't you lost the capability to browse the history of changes in your code? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] [pharo-project/pharo-core] 8be654: 40392
Log Message: --- 40392 14546 Failed inherited tests should show home class (in TestRunner, like the debugger) https://pharo.fogbugz.com/f/cases/14546 Thanks for this Nicolai. I only logged the idea yesterday, and here it is integrated overnight before I get home from work to review it. The yellow highlight in the attached picture shows the new feature. cheers -ben
[Pharo-dev] 14353 Delay refactoring (part 2) - change from milliseconds to microseconds
The change of Delay from milliseconds to microseconds is ready for human review. (https://pharo.fogbugz.com/default.asp?14353) With this change from milliseconds to microseconds, clock rollover is eliminated, but it seems Delays run at reduced performance. newCodeEnabled FALSE TRUE 128507 101227 delays scheduled per second 100%79% relative performance 7.8 9.9 microseconds per scheduled delay 100%127% relative performance I guess this is due to the move from 32bit millisecond immediate SmallIntegers to 64bit microsecond boxed LargePositiveIntegers. It would be interesting to check this on Spur64, but for now, is this performance penalty a reasonable trade for eliminating delay clock rollover? The Delay class comment warns of the critical performance its high priority event loop, and on paper a 21% drop in performance seems significant, but actually the main Morph interCyclePause is 50 milliseconds. So... (9.9 - 7.8) / 5 = 0.004% difference in performance. (Did I get that right?) Comments? P.S. DelayBenchmark results... === DelayBenchmark withNewCodeEnabled: true... #ConcurrentDelays: 1000 . Count: 39018 per second #ConcurrentDelays: 2000 . Count: 71906 per second #ConcurrentDelays: 3000 . Count: 98010 per second #ConcurrentDelays: 4000 . Count: 101227 per second #ConcurrentDelays: 5000 . Count: 64728 per second #ConcurrentDelays: 6000 . Count: 90495 per second #ConcurrentDelays: 7000 . Count: 89220 per second #ConcurrentDelays: 8000 . Count: 89585 per second #ConcurrentDelays: 9000 . Count: 88393 per second #ConcurrentDelays: 1 . Count: 89073 per second DelayBenchmark withNewCodeEnabled: false... #ConcurrentDelays: 1000 . Count: 39498 per second #ConcurrentDelays: 2000 . Count: 77808 per second #ConcurrentDelays: 3000 . Count: 99889 per second #ConcurrentDelays: 4000 . Count: 117632 per second #ConcurrentDelays: 5000 . Count: 128507 per second #ConcurrentDelays: 6000 . Count: 118729 per second #ConcurrentDelays: 7000 . Count: 114437 per second #ConcurrentDelays: 8000 . Count: 114792 per second #ConcurrentDelays: 9000 . Count: 115137 per second #ConcurrentDelays: 1 . Count: 113973 per second
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: * Made my first contribution to the VM, adding modifier keypress events for OSX. * Refactored class variables and class-side methods of Delay to instance side of new DelayScheduler. ### What's next, until 2014-12-14 (*): * Change Delays/DelayScheduler base from milliseconds to microseconds, to fix the commandline issue with super fast delay * Factor out the mutex interthread synchronisation code and provide some alternatives (e.g. Semaphore Spinlock) (*) we'll be expecting results by then ;)
[Pharo-dev] [pharo-project/pharo-core] 6f6c06: 40393
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f6c06023fa6406371a1e66a33159f03ea6427a2 https://github.com/pharo-project/pharo-core/commit/6f6c06023fa6406371a1e66a33159f03ea6427a2 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-12-01 (Mon, 01 Dec 2014) Changed paths: M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/fontContents.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installAllFontsIn_.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installFontsIn_.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/originalFileName.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/accessing/current.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/extra fonts registration/registerFont_.st R EmbeddedFreeType.package/OpenSansRegular.class/README.md R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/fontContents.st R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/originalFileName.st R EmbeddedFreeType.package/OpenSansRegular.class/class/class initialization/initialize.st R EmbeddedFreeType.package/OpenSansRegular.class/definition.st M EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/defaultFontName.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/setSourceCodeFontsDefault.st M EmbeddedFreeType.package/SourceCodeFonts.class/class/font registration/registerFonts_.st A EmbeddedFreeType.package/SourceSansProRegular.class/README.md A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/fontContents.st A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/originalFileName.st A EmbeddedFreeType.package/SourceSansProRegular.class/class/class initialization/initialize.st A EmbeddedFreeType.package/SourceSansProRegular.class/definition.st M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateEmbeddedFreeTypeFonts.st M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateFromSystem.st M FreeType.package/FreeTypeSettings.class/class/startup/startUp_.st A FreeType.package/FreeTypeSettings.class/class/startup/updateFreeType.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script393.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40393.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 40393 14553 FreeType default fonts not correctly loaded when image initializes https://pharo.fogbugz.com/f/cases/14553 http://files.pharo.org/image/40/40393.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40393 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] [pharo-project/pharo-core]
but it didn’t work so we will need to insist :( Esteban On 01 Dec 2014, at 18:13, GitHub nore...@github.com wrote: Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f6c06023fa6406371a1e66a33159f03ea6427a2 https://github.com/pharo-project/pharo-core/commit/6f6c06023fa6406371a1e66a33159f03ea6427a2 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-12-01 (Mon, 01 Dec 2014) Changed paths: M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/fontContents.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installAllFontsIn_.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installFontsIn_.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/originalFileName.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/accessing/current.st M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/extra fonts registration/registerFont_.st R EmbeddedFreeType.package/OpenSansRegular.class/README.md R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/fontContents.st R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/originalFileName.st R EmbeddedFreeType.package/OpenSansRegular.class/class/class initialization/initialize.st R EmbeddedFreeType.package/OpenSansRegular.class/definition.st M EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/defaultFontName.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/setSourceCodeFontsDefault.st M EmbeddedFreeType.package/SourceCodeFonts.class/class/font registration/registerFonts_.st A EmbeddedFreeType.package/SourceSansProRegular.class/README.md A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/fontContents.st A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/originalFileName.st A EmbeddedFreeType.package/SourceSansProRegular.class/class/class initialization/initialize.st A EmbeddedFreeType.package/SourceSansProRegular.class/definition.st M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateEmbeddedFreeTypeFonts.st M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateFromSystem.st M FreeType.package/FreeTypeSettings.class/class/startup/startUp_.st A FreeType.package/FreeTypeSettings.class/class/startup/updateFreeType.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script393.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40393.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 40393 14553 FreeType default fonts not correctly loaded when image initializes https://pharo.fogbugz.com/f/cases/14553 http://files.pharo.org/image/40/40393.zip
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
On Mon, Dec 1, 2014 at 5:51 PM, Ben Coman b...@openinworld.com wrote: seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: * Made my first contribution to the VM, adding modifier keypress events for OSX. Thanks a lot for that! :) Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
Hi Dale, On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs dale.henri...@gemtalksystems.com wrote: Eliot, If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ... `adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ... So *please* continue to be stubborn :-) My statement about as the community begins to use git-based repos as their primary repository includes a broad definition of community, in my mind:) +1 Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ... So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?) Which would be reasonable, but it needs to be there. And thanks. Dale On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda eliot.mira...@gmail.com wrote: Hi Dale, On Nov 30, 2014, at 8:14 AM, Dale Henrichs dale.henri...@gemtalksystems.com wrote: On Sun, Nov 30, 2014 at 7:51 AM, kilon alios kilon.al...@gmail.com wrote: So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ... The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history. When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an irreversible commitment to git. Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too. I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ... As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ... Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello? Dale -- best, Eliot
Re: [Pharo-dev] Duration year
Hi. I was working on a GenericYear that was intended to be used for DateAndTime calculus - to be able to add and subtract an arbitrary number of years. The class by itself would not know the days - it is an arbitrary (generic) Year. It would only know the number of days when it is added (or subtracted) from an actual date (or timespan). The idea was that it would have a very specific and limited scope of responsibility. -cbc On Sat, Nov 22, 2014 at 3:03 AM, Hilaire hila...@drgeo.eu wrote: I saw some discussion about Duration and year calculus in the list Given that it is impossible to determine the number of days in a year without the calendar years, should not 365.25 be used in place of 365 to minimize the error ? So it could look like: Duration class years: aNumber ^ self days: (aNumber * 365.25) truncated seconds: 0 Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
El Mon Dec 01 2014 at 12:19:53 PM, Andreas Wacknitz a.wackn...@gmx.de escribió: Am 01.12.14 12:34, schrieb kilon alios: No of course not. That would have been a deal braker. Personally I prefer using Sourcetree to browser history of commits than using the pharo on board tools. Pharo is good on that respect, but sourcetree is better Alas Sourcetree is only available for Windows and Mac OSX. Non-portable programs die with their system. Closed source programs die with their company. It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you.
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
On 01 Dec 2014, at 19:11, Eliot Miranda eliot.mira...@gmail.com wrote: Hi Dale, On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@gemtalksystems.com wrote: Eliot, If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ... `adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ... So *please* continue to be stubborn :-) but this is a limitation of gitfiletree. real git integration (using libgit2) should be perfectly capable of reconstruct history without any metadata. also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. Esteban My statement about as the community begins to use git-based repos as their primary repository includes a broad definition of community, in my mind:) +1 Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ... So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?) exactly. Which would be reasonable, but it needs to be there. And thanks. Dale On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda eliot.mira...@gmail.com mailto:eliot.mira...@gmail.com wrote: Hi Dale, On Nov 30, 2014, at 8:14 AM, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@gemtalksystems.com wrote: On Sun, Nov 30, 2014 at 7:51 AM, kilon alios kilon.al...@gmail.com mailto:kilon.al...@gmail.com wrote: So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ... The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history. When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an irreversible commitment to git. Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too. I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ... As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ... Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello? Dale -- best, Eliot
[Pharo-dev] ubuntu vm build
Hi, I forgot who is maintaining the ubuntu launchpad ppa vm build. But whoever you are ( :) ) would it be possible to include a vm build for the actual ubuntu release utopic unicorn? thanks, Norbert
Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14
On Mon, Dec 1, 2014 at 2:00 AM, seas...@rmod.lille.inria.fr wrote: Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - I gave 3 Smalltalk/Pharo related presentations (Web Development with Smalltalk, Smalltalk and Business, and Marea) at http://ilas.memi.umss.edu.bo/ (sponsored by ESUG). Slides: http://www.slideshare.net/MarianoMartinezPeck/web-development-with-smalltalk http://www.slideshare.net/MarianoMartinezPeck/smalltalk-and-business http://www.slideshare.net/MarianoMartinezPeck/thesis-presentation-14987645 I hope at least to get some guys involved! ### What's next, until 2014-12-14 (*): Back to work and update CV. (*) we'll be expecting results by then ;) -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
Le 01/12/2014 19:21, Esteban Lorenzano a écrit : On 01 Dec 2014, at 19:11, Eliot Miranda eliot.mira...@gmail.com mailto:eliot.mira...@gmail.com wrote: Hi Dale, On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@gemtalksystems.com wrote: Eliot, If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ... `adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ... So *please* continue to be stubborn :-) but this is a limitation of gitfiletree. This is a limitation of FileTree, not GitFileTree. real git integration (using libgit2) should be perfectly capable of reconstruct history without any metadata. As GitFileTree has been doing without libgit2 for, how long already? also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry Esteban My statement about as the community begins to use git-based repos as their primary repository includes a broad definition of community, in my mind:) +1 Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ... So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?) exactly. Which would be reasonable, but it needs to be there. And thanks. Dale On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda eliot.mira...@gmail.com mailto:eliot.mira...@gmail.com wrote: Hi Dale, On Nov 30, 2014, at 8:14 AM, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@gemtalksystems.com wrote: On Sun, Nov 30, 2014 at 7:51 AM, kilon alios kilon.al...@gmail.com mailto:kilon.al...@gmail.com wrote: So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ... The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history. When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an irreversible commitment to git. Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too. I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ... As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ... Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello? Dale -- best, Eliot
Re: [Pharo-dev] Duration year
I think we discussed this a few months ago. The problem is unsolvable as it is now, IMHO, because all the chronology objects are based on offset representations (since an epoch), instead of a field based representation. IMHO, the only way to have a proper semantic representation is to have field based date classes (like Java's Calendar object, not the best implementation though). Ej, which one of the followings is OK? '2012-02-29' asDate + 1 year = 2013-02-28 '2011-03-01' asDate + 1 year = 2012-02-29 '2011-03-01' asDate addMonths: 12 = 2012-03-01 Regards! El Mon Dec 01 2014 at 3:11:56 PM, Chris Cunningham cunningham...@gmail.com escribió: Hi. I was working on a GenericYear that was intended to be used for DateAndTime calculus - to be able to add and subtract an arbitrary number of years. The class by itself would not know the days - it is an arbitrary (generic) Year. It would only know the number of days when it is added (or subtracted) from an actual date (or timespan). The idea was that it would have a very specific and limited scope of responsibility. -cbc On Sat, Nov 22, 2014 at 3:03 AM, Hilaire hila...@drgeo.eu wrote: I saw some discussion about Duration and year calculus in the list Given that it is impossible to determine the number of days in a year without the calendar years, should not 365.25 be used in place of 365 to minimize the error ? So it could look like: Duration class years: aNumber ^ self days: (aNumber * 365.25) truncated seconds: 0 Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you. +1000 exactly and that is something I advocate. You cant use Sourcetree on linux ? no problemo use SmartGit you prefer using Emacs ? no problemo use magit. you prefer the terminal ? no problemo use the terminal. The cool thing is that it does not really matter what you choose because all tools follow the git workflow, the rest is just a matter of preference. The disadvantage of sticking just with Pharo ? you will be lucky to be able to use a single tool and you will be also lucky if that tool has a substantial fraction of the features of some of the external tools. Bigger community , bigger competition and cooperation. Quantity brings quality. Non-portable programs die with their system. Good luck waiting for MacOS and Windows to die. Closed source programs die with their company. a) if something dies that does not make it useless b) The beauty of capitalism is that as long there is demand there is going to be supply. So you will never run out of options. Aint working like that with open source I am afraid. I am all for open source, I am a huge fan and if I could I would use 100% open source if it satisfied me but you cant just push under the carpet the advantages of closed source software even if you are Richard Stallman. Plus we are MIT not GPL ;)
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier thierry.goub...@gmail.com wrote: Le 01/12/2014 19:21, Esteban Lorenzano a écrit : also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry, Not sure if you are being sarcastic here:) I just don't see how the current FileTree format delays git integration in the Pharo platform. I consider git integrated into tODE and tODE uses FileTree. Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the system browser so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files... A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages]. FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser. So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system. Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ... Dale [1] https://github.com/rjsargent/CypressReferenceImplementation
Re: [Pharo-dev] ubuntu vm build
Hello Norbert, the ubuntu vm build is in the process of being switched from Damien Cassou to me. I will update the PPA asap. Markus On 01.12.2014 19:36, Norbert Hartl wrote: Hi, I forgot who is maintaining the ubuntu launchpad ppa vm build. But whoever you are ( :) ) would it be possible to include a vm build for the actual ubuntu release utopic unicorn? thanks, Norbert
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
Am 01.12.14 um 19:56 schrieb kilon alios: It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you. +1000 exactly and that is something I advocate. You cant use Sourcetree on linux ? no problemo use SmartGit you prefer using Emacs ? no problemo use magit. you prefer the terminal ? no problemo use the terminal. I prefer the Smalltalk environment. The cool thing is that it does not really matter what you choose because all tools follow the git workflow, the rest is just a matter of preference. The disadvantage of sticking just with Pharo ? you will be lucky to be able to use a single tool and you will be also lucky if that tool has a substantial fraction of the features of some of the external tools. Bigger community , bigger competition and cooperation. Quantity brings quality. Sorry, if that would be true then Java or C# would be of extraordinary quality. Smalltalk has been there for more than 30 years and will probably another 30 years. Hypes come and go. Quantity for me seems more like the opposite of quality. Non-portable programs die with their system. Good luck waiting for MacOS and Windows to die. Why shouldn't they be able to die? There have been other successful companies before. Do you remember Netware? The market leader in networking, almost gone. What about DEC? Gone. Windows is already declining and the Microsoft desparately tries to find new ways to get back. Regarding Apple: They seem to be more interested in iPhone and iPad than in Macs. Obviously they earn a lot more in this field. IMO Apple and Microsoft have one thing in common these days: they make their products life style products that can be used by everybody. Alas for your work needs their operating systems get worse with every release. Windows XP and Snow Leopard are being seen as the best versions by some... Nothing lasts forever so you can be sure that Windows and Mac OSX will die some day. Closed source programs die with their company. a) if something dies that does not make it useless b) The beauty of capitalism is that as long there is demand there is going to be supply. So you will never run out of options. Aint working like that with open source I am afraid. That is not quite true. Look at what Oracle did with Solaris: They are not interested in the mass market. If you don't have millions (better billions) to spend they don't care about you. That's also possible in capitalism: you can ask very high prices so most people and companies cannot (or will not) be able to affort it or you can deny to sell a product. You don't even need a good explanation for it. I am all for open source, I am a huge fan and if I could I would use 100% open source if it satisfied me but you cant just push under the carpet the advantages of closed source software even if you are Richard Stallman. Plus we are MIT not GPL ;) My comment was not about discussing the pros and cons of closed versus open source software. My concerns are more about reliability. For me it's totally Ok to use git for versioning IF the tools are there. Squak and Pharo have decent versioning systems that suit their internal needs. There is room for improvements, that's for sure. For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily. Andreas
Re: [Pharo-dev] SmalltalkHub bugs hangs :-(
My comment was not about discussing the pros and cons of closed versus open source software. My concerns are more about reliability. For me it's totally Ok to use git for versioning IF the tools are there. Squak and Pharo have decent versioning systems that suit their internal needs. There is room for improvements, that's for sure. For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily. The problem is whether the tools you choose for commoditized tasks (e.g. SCM) limit the amount of manpower that could contribute to your open source project. Forks and pull-requests are the way most open source projects fix bugs and integrates enhancements. You can't do branching with current tooling (read: Monticello) without suffering proportional to its complexity. No one said tools can be replaced easily, and that's the reason we still use Monticello, some of us backed by old mcz files, others already using some git behind it. Regards,
Re: [Pharo-dev] ubuntu vm build
Hello Norbert, I tried using the copy feature - can you check if it worked? Kind regards Markus On 01.12.2014 19:36, Norbert Hartl wrote: Hi, I forgot who is maintaining the ubuntu launchpad ppa vm build. But whoever you are ( :) ) would it be possible to include a vm build for the actual ubuntu release utopic unicorn? thanks, Norbert
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
On 01 Dec 2014, at 20:25, Dale Henrichs dale.henri...@gemtalksystems.com wrote: On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: Le 01/12/2014 19:21, Esteban Lorenzano a écrit : also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry, Not sure if you are being sarcastic here:) he was, don’t worry :) and as an aswer: yes, I’m not happy with filetree format, but I wouldn’t spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement) but… in the not so far future the metadata *needs* to change, I’m sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve that… even with mergetools from Thierry, is too complicated). Esteban I just don't see how the current FileTree format delays git integration in the Pharo platform. I consider git integrated into tODE and tODE uses FileTree. Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the system browser so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files... A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages]. FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser. So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system. Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ... Dale [1] https://github.com/rjsargent/CypressReferenceImplementation https://github.com/rjsargent/CypressReferenceImplementation
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
Le 01/12/2014 20:25, Dale Henrichs a écrit : On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: Le 01/12/2014 19:21, Esteban Lorenzano a écrit : also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry, Not sure if you are being sarcastic here:) I wish I was :( I just don't see how the current FileTree format delays git integration in the Pharo platform. This is exactly my point. It works, it is cross-platform (mcz to FileTree and back), it has a significant bug squashing done, it's stable. Yes, it's not perfect. Metadata is noisy in github output, it used to cause problem when merging, and there is issues with very long path and file names. However, all discussions about changing the file format around Pharo brings no convincing arguments... just cosmetic changes, which basically says: lets do the same as before, but not compatible and with a new code base so that we can have our own new bugs. (If I had to redesign the file format for git use, I'd consider FileOut with a better parser, and alphabetical ordering: minimal code for reading and writing. But I'd loose some of the features that tODE has when querying the git logs). I consider git integrated into tODE and tODE uses FileTree. Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the system browser so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files... I agree. But you are at the point where you just say: libgit2 or GitFileTree are just means to an end: better tools to tap in the power of git and do something interesting with it. Look the situation of Pharo... They are still trying to get the infrastructure working. Yes, libgit2 will be better than GitFileTree, but barely, and how many years will Pharo have invested for that? In the mean time, what should I invest in? A GitFileTree which will be wasted anyway? And in a few years time, will NativeBoost still be in use? Or replaced by FFI and LowCode? With libgit2 reimplemented? With no support of libgit2 on ARM? And for what? The goal is to hide git behind any package and source management tools we have in the image, after all. A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages]. FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser. So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system. Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ... Yes, this is it: that focus is interesting. That's why I refer to tODE when I say you are showing us the way on git. But Pharo is a long way from being that ambitious. Thierry
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
On 01 Dec 2014, at 21:15, Thierry Goubier thierry.goub...@gmail.com wrote: Le 01/12/2014 20:25, Dale Henrichs a écrit : On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: Le 01/12/2014 19:21, Esteban Lorenzano a écrit : also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry, Not sure if you are being sarcastic here:) I wish I was :( I just don't see how the current FileTree format delays git integration in the Pharo platform. This is exactly my point. It works, it is cross-platform (mcz to FileTree and back), it has a significant bug squashing done, it's stable. Yes, it's not perfect. Metadata is noisy in github output, it used to cause problem when merging, and there is issues with very long path and file names. However, all discussions about changing the file format around Pharo brings no convincing arguments... just cosmetic changes, which basically says: lets do the same as before, but not compatible and with a new code base so that we can have our own new bugs. (If I had to redesign the file format for git use, I'd consider FileOut with a better parser, and alphabetical ordering: minimal code for reading and writing. But I'd loose some of the features that tODE has when querying the git logs). I consider git integrated into tODE and tODE uses FileTree. Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the system browser so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files... I agree. But you are at the point where you just say: libgit2 or GitFileTree are just means to an end: better tools to tap in the power of git and do something interesting with it. Look the situation of Pharo... They are still trying to get the infrastructure working. Yes, libgit2 will be better than GitFileTree, but barely, and how many years will Pharo have invested for that? In the mean time, what should I invest in? A GitFileTree which will be wasted anyway? And in a few years time, will NativeBoost still be in use? Or replaced by FFI and LowCode? With libgit2 reimplemented? With no support of libgit2 on ARM? And for what? The goal is to hide git behind any package and source management tools we have in the image, after all. well, no. the goal is to not needing to install git command line to use it (is a requirement: pharo needs to keep being as portable and independent as always) :) from my point of view, I’m quite happy with gitfiletree. I will just intend to make it work without OSProcess. but in other discussions. Yes, we will need to stabilise things in a point. I’m not happy with general status of… well, a lot of things. And not in status of stability (most of them work really well), but I’m working to try to ensure the maintainability in the long way… and that includes time to time needing to admit that we cannot maintain everything (thus my push of (git)filetree and the use of git in general) Esteban A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages]. FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser. So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system. Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ... Yes, this is it: that focus is interesting. That's why I refer to tODE when I say you are showing us the way on git. But Pharo is a long way from being that
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
Le 01/12/2014 21:04, Esteban Lorenzano a écrit : On 01 Dec 2014, at 20:25, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@gemtalksystems.com wrote: On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: Le 01/12/2014 19:21, Esteban Lorenzano a écrit : also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry, Not sure if you are being sarcastic here:) he was, don’t worry :) Maybe I was :) and as an aswer: yes, I’m not happy with filetree format, but I wouldn’t spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement) When I considered libgit2 a while ago, I was like you: a must. Then I saw that: libgit2 was low-level = lot's of code in Pharo do do simple, basic stuff. libgit2 required changes in NativeBoost = what, NativeBoost isn't ready? Pharo is stuck in 32bits land=No libgit2 by default on target OS. NativeBoost is x86 only? No libgit2 on ARM. In short: I don't have the resources to do that. It's too expensive for the benefits. I'm impressed by Max and your dedication. but… in the not so far future the metadata *needs* to change, I’m sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve that… even with mergetools from Thierry, is too complicated). The way you say it, I wonder if you understand what the MergeDriver is supposed to solve (and what it isn't). You'll have to say more ;) (especially the bit about the merge of large projects/multiple developers being too complicated...) Thierry Esteban
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
On 01 Dec 2014, at 21:48, Thierry Goubier thierry.goub...@gmail.com wrote: Le 01/12/2014 21:04, Esteban Lorenzano a écrit : On 01 Dec 2014, at 20:25, Dale Henrichs dale.henri...@gemtalksystems.com mailto:dale.henri...@gemtalksystems.com wrote: On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com wrote: Le 01/12/2014 19:21, Esteban Lorenzano a écrit : also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry, Not sure if you are being sarcastic here:) he was, don’t worry :) Maybe I was :) and as an aswer: yes, I’m not happy with filetree format, but I wouldn’t spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement) When I considered libgit2 a while ago, I was like you: a must. Then I saw that: libgit2 was low-level = lot's of code in Pharo do do simple, basic stuff. libgit2 required changes in NativeBoost = what, NativeBoost isn't ready? Pharo is stuck in 32bits land=No libgit2 by default on target OS. NativeBoost is x86 only? No libgit2 on ARM. I’m also concerned about that (32bits only). But we are already working on a solution. (and libgit2 support is already there, thanks to Max). as I said… our problem (not yours, but ours) is that we need to keep pharo independent of installed tools. So… libgit2. Otherwise I would be pushing gitfiletree a lot more loud :) Esteban In short: I don't have the resources to do that. It's too expensive for the benefits. I'm impressed by Max and your dedication. but… in the not so far future the metadata *needs* to change, I’m sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve that… even with mergetools from Thierry, is too complicated). The way you say it, I wonder if you understand what the MergeDriver is supposed to solve (and what it isn't). You'll have to say more ;) (especially the bit about the merge of large projects/multiple developers being too complicated...) Thierry Esteban
[Pharo-dev] [To be merged] GT-InspectorExtensions-Core-SvenVanCaekenberghe.77
In Moose/GToolkit: === Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.77 Author: SvenVanCaekenberghe Time: 1 December 2014, 9:56:58.104994 pm UUID: 3da8544f-909e-49c6-88a5-f944a5f13b42 Ancestors: GT-InspectorExtensions-Core-TudorGirba.76 New version of Float#gtInspectorFloatIn: that shows the new binary presentation available in Pharo 4. Tests on availability of #binaryLiteralString so that this change should remain compatible with Pharo 3. Thx Kris Gybels for this contribution. === To be merged with higher versions (this was based on the version present in Pharo 4 today). Sven
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
Le 01/12/2014 21:53, Esteban Lorenzano a écrit : I’m also concerned about that (32bits only). But we are already working on a solution. (and libgit2 support is already there, thanks to Max). as I said… our problem (not yours, but ours) is that we need to keep pharo independent of installed tools. So… libgit2. Otherwise I would be pushing gitfiletree a lot more loud :) Yes. This is a strong point. I considered bundling a git along, to solve issues like Stephan's. Bundling libgit2 is a bit similar, in a way. Mind you. I do prefer the libgit2 + NativeBoost... but it was far too costly. And still not that portable (i.e. no git on the RaspberryPi, for example). And some of my internal arguments for libgit2 (being able to correctly propagate a Monticello merge into git) were wrong, but it took me time and the MergeDriver to understand why. Thierry
Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree
Le 01/12/2014 21:39, Esteban Lorenzano a écrit : the goal is to not needing to install git command line to use it (is a requirement: pharo needs to keep being as portable and independent as always) :) from my point of view, I’m quite happy with gitfiletree. I will just intend to make it work without OSProcess. I can understand that intent. but in other discussions. Yes, we will need to stabilise things in a point. I’m not happy with general status of… well, a lot of things. And not in status of stability (most of them work really well), but I’m working to try to ensure the maintainability in the long way… and that includes time to time needing to admit that we cannot maintain everything (thus my push of (git)filetree and the use of git in general) And I can only thank all the Pharo team for the impressive stability going from Pharo3 to Pharo4. Thierry Esteban
[Pharo-dev] Pharo - [ANN] SimpleDDS v1.0 released.
Hi guys, i am just releasing SimpleDDS. In order to connect into ROS world i had to implement a DDS support (Publisher/subscriber). For achieving this i did MetaDDS, a library that defines basic objects, announcements, event related mechanisms and data encoding formats, and on top of it SimpleDDS, which is ROS based. SimpleDDS Has a package of examples highly commented for learning how to use it. The comments are also in the Github wiki, as wiki pages: https://github.com/sbragagnolo/SimpleDDS/wiki Gofer it smalltalkhubUser: 'sbragagnolo' project: 'SimpleDDS'; configuration; loadVersion: #stable Here some links about http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern http://en.wikipedia.org/wiki/Data_Distribution_Service Thats it. Enjoy. Santiago
Re: [Pharo-dev] [To be merged] GT-InspectorExtensions-Core-SvenVanCaekenberghe.77
Where do I find this one? Doru On Mon, Dec 1, 2014 at 10:04 PM, Sven Van Caekenberghe s...@stfx.eu wrote: In Moose/GToolkit: === Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.77 Author: SvenVanCaekenberghe Time: 1 December 2014, 9:56:58.104994 pm UUID: 3da8544f-909e-49c6-88a5-f944a5f13b42 Ancestors: GT-InspectorExtensions-Core-TudorGirba.76 New version of Float#gtInspectorFloatIn: that shows the new binary presentation available in Pharo 4. Tests on availability of #binaryLiteralString so that this change should remain compatible with Pharo 3. Thx Kris Gybels for this contribution. === To be merged with higher versions (this was based on the version present in Pharo 4 today). Sven -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [To be merged] GT-InspectorExtensions-Core-SvenVanCaekenberghe.77
http://www.smalltalkhub.com/#!/~Moose/GToolkit On 01 Dec 2014, at 23:18, Tudor Girba tu...@tudorgirba.com wrote: Where do I find this one? Doru On Mon, Dec 1, 2014 at 10:04 PM, Sven Van Caekenberghe s...@stfx.eu wrote: In Moose/GToolkit: === Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.77 Author: SvenVanCaekenberghe Time: 1 December 2014, 9:56:58.104994 pm UUID: 3da8544f-909e-49c6-88a5-f944a5f13b42 Ancestors: GT-InspectorExtensions-Core-TudorGirba.76 New version of Float#gtInspectorFloatIn: that shows the new binary presentation available in Pharo 4. Tests on availability of #binaryLiteralString so that this change should remain compatible with Pharo 3. Thx Kris Gybels for this contribution. === To be merged with higher versions (this was based on the version present in Pharo 4 today). Sven -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [To be merged] GT-InspectorExtensions-Core-SvenVanCaekenberghe.77
Ugh. Sorry, I missed it. It's merged now. Cheers, Doru On Mon, Dec 1, 2014 at 11:28 PM, Sven Van Caekenberghe s...@stfx.eu wrote: http://www.smalltalkhub.com/#!/~Moose/GToolkit On 01 Dec 2014, at 23:18, Tudor Girba tu...@tudorgirba.com wrote: Where do I find this one? Doru On Mon, Dec 1, 2014 at 10:04 PM, Sven Van Caekenberghe s...@stfx.eu wrote: In Moose/GToolkit: === Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.77 Author: SvenVanCaekenberghe Time: 1 December 2014, 9:56:58.104994 pm UUID: 3da8544f-909e-49c6-88a5-f944a5f13b42 Ancestors: GT-InspectorExtensions-Core-TudorGirba.76 New version of Float#gtInspectorFloatIn: that shows the new binary presentation available in Pharo 4. Tests on availability of #binaryLiteralString so that this change should remain compatible with Pharo 3. Thx Kris Gybels for this contribution. === To be merged with higher versions (this was based on the version present in Pharo 4 today). Sven -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Pharo - [ANN] SimpleDDS v1.0 released.
Wow, impressive.
Re: [Pharo-dev] Pharo - [ANN] SimpleDDS v1.0 released.
Santiago Bragagnolo wrote: Hi guys, i am just releasing SimpleDDS. In order to connect into ROS world i had to implement a DDS support (Publisher/subscriber). For achieving this i did MetaDDS, a library that defines basic objects, announcements, event related mechanisms and data encoding formats, and on top of it SimpleDDS, which is ROS based. SimpleDDS Has a package of examples highly commented for learning how to use it. The comments are also in the Github wiki, as wiki pages: https://github.com/sbragagnolo/SimpleDDS/wiki Gofer it smalltalkhubUser: 'sbragagnolo' project: 'SimpleDDS'; configuration; loadVersion: #stable Here some links about http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern http://en.wikipedia.org/wiki/Data_Distribution_Service Thats it. Enjoy. Santiago I haven't heard of DDS, but this seems really significant! From wikipedia... DDS addresses the needs of applications like financial trading, air-traffic control, smart grid management, and other Big data applications. The standard is used in applications such as smartphone operating systems,[1] transportation systems and vehicles,[2] software-defined radio, and by healthcare providers. This could be a nice lead into these application domains. If this got to a sufficient level of features, maybe Santiago could even be sponsored to attend an interoperability meeting? DDS vendors participated in _Interoperability demonstrations_ at the Object Management Group (OMG) Spring Technical Meeting.[7] During the demo, each vendor publishes and subscribes to each other's topics using a test suite called the Shapes Demo. Such might be a good place to network and demo general use of Pharo. cheers -ben
[Pharo-dev] Scale in 3.0 (kind of ANN)
I've put Guille's Scale thing ( http://guillep.github.io/blog/2014/01/23/replacing-bash-with-pharo/) into Pharo 3.0 Details on how to use here: http://smalltalkhub.com/#!/~philippeback/Scale Enjoy, Phil
[Pharo-dev] GetOpt
I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 See: http://www.smalltalkhub.com/#!/~philippeback/GetOpt Nice tool even if we have some other support in CommandLineHandlers. But for a quick parameters setting in your own CommandLineHandler, it is fast to use and easy to debug. Phil
