Re: [Pharo-dev] [rmod] scripting pharo How to disable settings loading..
Hi, You need to add `--no-default-preferences` after the image name. pharo80 /Users/ducasse/Documents/Pharo/images/P8Indian/P8Indian.image --no-default-preferences --list On Wed, Jul 29, 2020 at 6:57 PM Stéphane Ducasse wrote: > > Hi > > I would like to write some scripts with Pharo. > Now I cannot find how to block the settings > because I have a crash in my settings > > > pharo80 /Users/ducasse/Documents/Pharo/images/P8Indian/P8Indian.image --list > pharo80 /Users/ducasse/Documents/Pharo/images/P8Indian/P8Indian.image —-help > pharo80 /Users/ducasse/Documents/Pharo/images/P8Indian/P8Indian.image -help > > All of them crash because my settings are broken > > > > doing the following does not help > > pharo80 --help > Usage: /Users/ducasse/bin/Pharo/Pharo64Stable.app/Contents/MacOS/Pharo > [...] [ [...]] >/Users/ducasse/bin/Pharo/Pharo64Stable.app/Contents/MacOS/Pharo > [...] -- [...] > > Common s: > --help print this help message, then exit > --memory [mk]use fixed heap size (added to image size) > --nohandlers disable sigsegv & sigusr1 handlers > --timephases print start load and run times > --breaksel selectorset breakpoint on send of selector > --breakmnu selectorset breakpoint on MNU of selector > --eden [mk] set eden memory to bytes > --leakcheck numcheck for leaks in the heap > --stackpages num use n stack pages > --numextsems num make the external semaphore table num in size > --noheartbeat disable the heartbeat for VM debugging. disables > input > --pollpip output . on each poll for input > --checkpluginwritescheck for writes past end of object in plugins > --trace[=num] enable tracing (optionally to a specific value) > --warnpid print pid in warnings > --codesize [mk] set machine code memory to bytes > --tracestores enable store tracing (assert check stores) > --cogmaxlitsset max number of literals for methods to be > compiled to machine code > --cogminjumps set min number of backward jumps for interpreted > methods to be considered for compilation to machine code > --reportheadroom report unused stack headroom on exit > --maxoldspace [mk] set max size of old space memory to bytes > --logscavenge log scavenging to scavenge.log > --headless run in headless (no window) mode (default: false) > --headfull run in headful (window) mode (default: true) > --version print version information, then exit > --blockonerror on error or segv block, not exit. useful for > attaching gdb > --blockonwarn on warning block, don't warn. useful for attaching > gdb > --exitonwarn treat warnings as errors, exiting on warn > > Notes: >defaults to `Pharo.image'. > If '--memory' or '-maxoldspace' are not specified then the heap will grow > dynamically. > s are ignored, but are processed by the Squeak image. > The first normally names a Squeak `script' to execute. > Precede by `--' to use default image. > > > > > Stéphane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Not seeing hidden character is confusing :)
Shift + space = insecable space It would be cool to be able to toggle a mode as in text editor where hidden characters are represented by a symbol. https://www.avrfreaks.net/sites/default/files/notepadpp.PNG On Mon, Apr 13, 2020 at 8:44 PM Stéphane Ducasse wrote: > > Hi > > I have the impression that we can introduce hidden characters > while typing code and this is a problem to me because we do not see them :) > I got for example selhiddenf and it can lead to strange situations. > > I will try to chase the key combinations that produce them and see how we > can control and avoid this situation. > If you find the key combination please let me know. > > S. > > Stéphane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Happy new year!
On Tue 31 Dec 2019 at 11:45, Esteban Lorenzano wrote: > Hi, > > Just that, happy new year to everybody! :) > For 2020, let’s make a great Pharo 8 release and an even better Pharo 9. > > Cheers! > Esteban > Happy new year everyone! :) -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] MDLApplication
On Thu, Nov 28, 2019 at 11:26 AM Julien Delplanque wrote: > > Hello Sven, > > Did you try https://github.com/jecisc/MDBaseGenerator ? > To help with discoverability, I migrated the project from my repository to DuneSt. The previous link should still work with Github redirections. > It generates a nice template for starting a new MDL webapp. > > I do not know about MDLApplication. > > Cheers, > > Julien > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] MDLApplication
On Thu, Nov 28, 2019 at 11:17 AM Sven Van Caekenberghe wrote: > > Hi, > > I am trying to use MaterialDesignLite (master branch in Pharo 7). The demo > works perfectly. > > Now, I thought I would start writing a small web app by subclassing > MDLApplication, since that seems to set up things properly. > > Is that class finished ? How am I supposed to use it ? There are screens, but > how are these rendered ? Do I have to do this myself ? Must there not be an > idea of a current screen ? > > MDLScreen is in fact an empty class. > > Although there are units tests for MDLApplication, there is no subclass, so > no actual user. It feels a bit as if the demo should/could use it. > Hi, This class was introduced at the beginning of MDL and was used by its creator. This person does not contribute anymore and I never really used it so I do not know how useful it is. I will add an issue to take a look and either improve it or deprecate it to not make people lose time. https://github.com/DuneSt/MaterialDesignLite/issues/292 As Julien told you, I usually start a standard MDL application with the generator I wrote to get the basic infrastructure. I hope it helps you getting started smoothly. > Sven -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] BlueInk removal
On Wed, Nov 27, 2019 at 2:17 PM Sven Van Caekenberghe wrote: > > > > Yes, this could have been handled much better, I guess (I don't know the > details). > > But for day to day work, you have to use Pharo 7, which should be 100% > stable, while Pharo 8 is a moving target, an alpha version that is sometimes > broken. > Hi, I agree that the alpha version does not have to be stable all the time, but I still don't think it justify to not deprecate things. When you are working on stable version only, it is still better to be able to migrate your projects from one version to the other via the deprecation than to have everything broken and not loadable. If you can't even load your code, it's much harder to fix it. So I still think that we should go via deprecations. It has really a low cost and make migrations so much easier. Especially it give us time instead of giving us an ultimatum "You want to change of version? Then you need to fix everything now". > Now, we still want users for Pharo 8, else there will be no feedback, so > there are certainly two sides to this argument. > > Sven > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] BlueInk removal
On Tue, Nov 26, 2019 at 6:29 PM ducasse wrote: > > Cyril > > We are crawling with too many things. > Pharo should start to lose fat FOR REAL. > I really hope that we will get rid of lot of old code in the future. > If Enlumineur does not work when we integrate it - I just issue a PR > then you will have a good case for reintegrating and having two formatter, > two contexts classes, > two packages full of nearly the same but not quite tests. > Yes but deprecation give us time to migrate. Now I cannot work on Moose because the dev version is broken since Roassal depends on GTEventRecorder and it was removed without deprecation. It's the second day in a row where I cannot work properly. And I don't know when Moose will be fixed because I don't know the code of roassal and I cannot fix it myself. So I have to wait that someone else fixes it. I understand that we want Pharo to be smaller but here it prevent people from working. And the size of those projects is nothing compared to the global size of Pharo and we are assured to be able to remove them just after the release of Pharo 8. > S. > > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] BlueInk removal
On Tue, Nov 26, 2019 at 2:07 PM ducasse wrote: > > Cyril can you wait until this evening? > We should remove old things and having the two side by side is a lot more > painful > to work. > We are still in Pharo 80 alpha. > > Stef > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything will be stricked and people will know they should not use it and it will help us migrate our settings without breaking everything. And deprecating it is just one method in the manifest. > > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] BlueInk removal
Hi, Can we revert the removal of blueink the time the new formatter is in the image please? (And maybe deprecate it instead of removing it). I ask this because: - If we work with Pharo 8 we need to format the code by hand because the format option is currently messing the code - The current formatter is removing all method comment - Currently removing it without deprecation is breaking the setting system (And since I push the setting system further than most people, I cannot even open an image with settings now...) I remind that the formatter is called by the refactorings. Imagine my surprise when I wanted to commit refactorings and I saw all the formatting messed up and all my method comments missing. I really do not appreciate to lose comments I spent time to write like this... -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] ZnBufferedReadWriteStream vs SourceFileBufferedReadWriteStream/SourceFileCharacterReadWriteStream
On Fri, Oct 11, 2019 at 2:32 PM Sven Van Caekenberghe wrote: > > I also do not understand how this was done in Pharo 7 *before* it was > finalised/fully debugged in Pharo 8. > > Back-porting must be done very carefully. > Hi Sven, One thing that must be know is that everything going in the Pharo 7 branch is not released directly. The changes you talk about are in no release currently. A release is launched manually currently when important changes are backported and stabilized. > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Easy first issues for Pharo contributors?
On Sun 6 Oct 2019 at 16:12, James Foster wrote: > All good suggestions. I especially like the executable examples idea since > that will demonstrate understanding of the code but still be easy to > describe and easy to confirm. Thanks! > Hi, Adding method, class and package comments is also simple and great for the community :) > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Cannot extract stable VM on Window
Le 29/09/2019 à 16:35, Brainstorms a écrit : > Hi Cyril, > > I downloaded it and tried it on Win7 Pro 64bit (running in Virtualbox), and > was able to open as expected. > > However, looking in the zip file itself, I noticed about two dozen > "*_Zone.Identifier" files that I was not expecting to see. They likely > should not be there; they have something to do with IT security inspections > on downloaded files, and I delete them as a matter of course whenever I see > them (as part of a download). I'm not sure why the Pharo build process > would have these. > > I tried launching Pharo from this zip file before and after I removed these > files... It worked in both cases; no corruption reported. However, since > your error dialog was reporting one of these 'zone' files, I would trying > removing them and see if that helps. > Thanks! With your comment I succeeded to launch my image. What I needed to do was to open the zip file without extracting it, delete all the .Identifier files and extract it once done. I wonder how the vm zip files end up with those files in them. > -Ted > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Cannot extract stable VM on Window
Le 29/09/2019 à 18:32, Christopher Fuhrman a écrit : > I reported an intermittent problem with pharo-launcher transferring > images that are detected as corrupted on my Windows 10. What happens > when you retry? > > See https://github.com/pharo-project/pharo-launcher/issues/359 > I already saw this issue but retrying was not working. I can reproduce it. -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Cannot extract stable VM on Window
Le 29/09/2019 à 15:53, Cyril Ferlicot D. a écrit : > Hi, > > Today I tried to extract the stable windows VM for Pharo 8 64bits on > Windows 7 but I get an error saying the file is corrupted. > > Link: http://files.pharo.org/vm/pharo-spur64/win/stable-20190916.zip > > Can someone reproduce it? > Also, I tried to take the latest VM but when I launch an image, no UI is opening. (And I took the pharo64-win-latest, not the pharo64-win-headless-latest) -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
[Pharo-dev] Cannot extract stable VM on Window
Hi, Today I tried to extract the stable windows VM for Pharo 8 64bits on Windows 7 but I get an error saying the file is corrupted. Link: http://files.pharo.org/vm/pharo-spur64/win/stable-20190916.zip Can someone reproduce it? -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses
On Fri 30 Aug 2019 at 09:34, Julien wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "an > OrderedCollection() » > > The question is then, who is right? > > Should #allButFirst: with an argument greater than the collection size > raise an error > > Or > > Should #allButFirst: with an argument greater than the collection size > returns an empty collection ? > > I asked a few people about it @ ESUG and it appears that the expected > behaviour from #allButFirst: is not the same to all people. > > We need to decide so we improve consistence of collections. > > And then, we need to document that with a test :-). > Hi, I was one of the person who discussed this with Julien at ESUG and IMO it should launch an error. While working on complexe models, errors in such cases are really really really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound help me a lot to find bugs and sometimes without this kind of methods it could have take me days to find the problem (and it’s only in the case I know there is a bug). > Cheers. > > Julien > > --- > Julien Delplanque > Doctorant à l’Université de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > Bâtiment B 40, Avenue Halley 59650 > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail=g> > Villeneuve > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail=g> > d'Ascq > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail=g> > Numéro de téléphone: +333 59 35 86 40 > > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] Class definition with slot template is broken
Hi, Since yesterday I get a lot of bugs when I try to edit class definitions while having the slot template in class definition enabled. (See comment: https://github.com/pharo-project/pharo/pull/4391) This make it a little hard to develop :( Is there an easy fix? Else maybe we should revert the change until we have the fix? Have a nice day! -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [Pharo-users] Information on Spec development
On Tue, Aug 13, 2019 at 3:25 PM Esteban Lorenzano wrote: > > > No, you are not :) > #asSpAdapter will be removed. > > You are looking for SpMorphPresenter (and/or the method SpPresenter>>newMorph) > In the Spec repository I deprecated #asSpAdapter with a mesage explaining SpMorphPresenter should be used. It will be integrated in next Spec integration. > Esteban > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [Pharo-users] Information on Spec development
On Tue, Aug 13, 2019 at 2:59 PM Norbert Hartl wrote: > > > Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in > the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead > of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. > What is the strategy for that. For now I did a #asSpec2Adapter in my image > that return the SpMorphic.. class. > Hi, The extensions in Spec2 are renamed to not conflict with Spec 1. You are looking for #asSpAdapter ;) > Norbert > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [Pharo-users] Information on Spec development
On Tue, Aug 13, 2019 at 1:35 PM Torsten Bergmann wrote: > > Cyril Ferlicot wrote: > >The revert of changes of Spec 1 is now done in Pharo 8. > > Nice - lots of work. Thanks!!! > > > All classes of Spec2 start with the Sp or TSp prefix. > > Maybe I'm wrong but: > > If "Sp" is the prefix for Spec2 and trait names start with "T" we should > used SpT... for traits, no? > Until now, the T is before the prefix. (For example TIceXXX for Iceberg). So I followed what was already done. > Otherwise it would not be a prefix ... > > Thanks > T. > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Information on Spec development
On Thu, Jun 20, 2019 at 5:29 PM Cyril Ferlicot wrote: > > Hello everyone! > > This is an important update about the development of Spec. > > As you might have heard, we are working on Spec to release a new > version in Pharo 8. One goal is to unify all Pharo interfaces behind > one GUI framework and a second goal is to allow multiple back-ends > (Morphic but also GTK, Bloc, ...). To reach those goals we have been > updating the current version of Spec. We see now, however, that > updating Spec directly creates troubles with migration. For example, > we currently have a lot of deprecation warnings in Iceberg, because we > can't update it without breaking Pharo 7 compatibility. > > After some discussions between the engineers working on Spec, here is > our plan to improve the situation: We will copy all classes of Spec > and rename them with the "Sp" prefix. (We will also ensure that every > class of Spec started with the same prefix for consistency). For > extensions methods, we will rename them to have a version different > from Spec 1 (The spec from Pharo 7). Once done we will integrate this > new version in Pharo 8. From there we will wait some weeks to let > users who started to use the updated Spec change their projects to use > this new Spec2. Finally, we will revert all changes that happened on > Spec 1 and deprecate the packages. We hope this will make things > easier for everyone. > > Have a nice day! Hi, The revert of changes of Spec 1 is now done in Pharo 8. Spec 1 is now in the same state than in Pharo 7 and Spec2 can live next to it. All classes of Spec2 start with the Sp or TSp prefix. Have a nice day. > > -- > Cyril Ferlicot > https://ferlicot.fr -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Impossible to create new protocol?
On Tue, Aug 13, 2019 at 9:18 AM ducasse wrote: > > Tx pavel. > I ask cyril to fix it :) > https://github.com/pharo-project/pharo/pull/4299 > > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] Why do we have 2 VTermOutputDriver?
Hi, In the image we currently have two VTermOutputDriver. The second one is not used but I have the impression that it was a WIP. Does someone knows what it the state of this class? Should we remove the second? Should the second be used instead of the first? -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
[Pharo-dev] Menu missing translation rule
Hi, I usually get really annoyed by the "Menu missing translation" rule because it has a huge false positive rate. I am the only one get many false positives? Does it make sense to keep this rule? What do you think? If all menus should be translated, maybe it's the menu itself that should send #translate to the argument. -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] SessionErrorHandlingTest UI lockup
On Sat, Jul 13, 2019 at 1:38 PM Ben Coman wrote: > > In Pharo 80482 I am experiencing a UI lockup running... > SessionErrorHandlingTest>>testErrorCaughtAndDefferedIfExceptionSignaledAtStartupWhenStartupUiManagerActive > > Can anyone else confirm? > I can confirm. I see the notification and it vanish but I cannot interact with the image anymore after. Tested on macOs. > cheers -ben > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [Pharo-users] Test Completion has been added to Pharo 8 - please test!
On Wed, Jul 3, 2019 at 2:29 AM Myroslava Romaniuk via Pharo-users wrote: > > Hi all, > > we added an intermediate version of the upcoming test completion to Pharo 8, > it would be cool if you tested it and let us know the results. Here's a blog > post about it - link, and here's a tweet I'd be grateful if you shared - link > so perhaps people who don't read the mailing list would also see it. In the > blog post you can find more info how to enable the completion in the settings > and details about the whole thing in general. If something doesn't work, or > if something works differently than it used to in the old completion (both if > you don't like it or perhaps if you prefer it) let me know either replying > here, on twitter, or submitting an issue request directly for the github > repository here - link. > Hi, Since the new code completion is enable I have problem with variables completion. I saw it the most with temporary variables that are not proposed for completion anymore. This is really annoying since I often have long variables names to be explicit in my code :( I hope it can help you improve it :) > Thanks very much, > Myroslava -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Changes proposal on Pre debugger
On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak wrote: > > Hi Cyril, > > I had a particular use-case in Sentry Logger (adopted from old ShoreLine > reporter) that added a "Report" button to the pre-debugger (via a > PreDebugAction subclass). Not having the button is fine for me (automated > reporting is always better), just wanted to mention it. > > What I am wondering more is whether eliminating the pre-debugger would make > it much harder to add something like "Production pre-debug window" that > contains alternative content that doesn't scare non-technical people. > > Not all users of Pharo are Pharo developers, so dropping on them the full > debugger is not good. > Would it be cleaner to enable by default the Always Open Full Debugger, and > then it can be toggled off when building production images? > > Or did you have some other alternatives in mind? > Hi Peter, With changes introduced with the GTDebbuger it is possible to register alternative debuggers. They have a priority and know if they need to open depending on the context. We discussed with Steven and Thomas from the RMoD team and we think this is cool like that we can register alternative debuggers. On top of that, we would like to add the concept of fallback in case there is a problem. Currently, when the debugger bug, the emergency evaluator is open. We would like to open the next available debugger instead of the emergency evaluator. Then the emergency evaluator would be the last in the list. Also, an another subject, the button report can still be added to the full debugger. > Peter > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Changes proposal on Pre debugger
https://github.com/pharo-project/pharo/pull/3883 On Wed, Jul 10, 2019 at 8:21 PM Cyril Ferlicot D. wrote: > > Hi, > > After talking with Steven (in copy) we agreed on possible improvements > around the pre debugger. I would like to share our vision and check if > the community agrees. > > Context: > > The pre debugger is the window opening when an exception is signalled > and not catched. This window currently has two views: > - On warnings it display a text explaining the encountered problem. You > can the proceed, abandon or debug. For example, this happens on > Deprecations. > - On other exceptions it display a short stack of the context in which > the error was raised. You can abandon, open a full debugger, ... > > Before, both views were managed via the same UI class. Yesterday I > slitted this class. > > Proposed change: > > In our opinion, the pre debugger displaying a stack is useless. All the > options it proposes are in the full debugger within one click reach. The > only value we see for the pre debugger is about warnings. > > Thus, we propose to remove the stack pre debugger and display directly > the full debugger for anything else than a warning. This will save > everyone one click each time we want to debug something. We would keep > the textual view for warnings. > > In case we do this, I wonder if we should keep the setting "Open full > debugger". I think most users of this option are using it in order to > not see the stack pre debugger and not to skip warnings. So, do someone > have an opinion about keeping or removing this setting in case we remove > the stack pre debugger? > > Possible future changes: > > In the future I would also like it if the opening of the pre (or full) > debugger would be delegated to the raised exception in order to allow > the introduction of different pre debuggers. But it's just an idea and > not the scope of this mail. :) > > -- > Cyril Ferlicot > https://ferlicot.fr > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Changes proposal on Pre debugger
On Thu, Jul 11, 2019 at 7:17 AM Ben Coman wrote: > > > I'm not sure how I feel. I usually click in the Pre-Debugger stack > rather than click the button. > When doing TDD I'll often know that the method I want to open is four > down in the stack rather than where the library method bombed out. > But really at worst its one additional click and probably easy enough > to adapt so I'm willing to give it a go. > Hi Ben, In your case there will be no change. You will still click one time four down in the stack. Or did I miss something? > cheers -ben > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] Changes proposal on Pre debugger
Hi, After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees. Context: The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ... Before, both views were managed via the same UI class. Yesterday I slitted this class. Proposed change: In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings. Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings. In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger? Possible future changes: In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :) -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] [Pharo-users] Information on Spec development
Spec 2 was integrated in Pharo. Here is the changelog: https://github.com/pharo-project/pharo/pull/3667 We will wait a few weeks before reverting all the changes to Spec 1 in order to let people who started to develop in Spec in Pharo 8 migrate to this version. -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
[Pharo-dev] Information on Spec development
Hello everyone! This is an important update about the development of Spec. As you might have heard, we are working on Spec to release a new version in Pharo 8. One goal is to unify all Pharo interfaces behind one GUI framework and a second goal is to allow multiple back-ends (Morphic but also GTK, Bloc, ...). To reach those goals we have been updating the current version of Spec. We see now, however, that updating Spec directly creates troubles with migration. For example, we currently have a lot of deprecation warnings in Iceberg, because we can't update it without breaking Pharo 7 compatibility. After some discussions between the engineers working on Spec, here is our plan to improve the situation: We will copy all classes of Spec and rename them with the "Sp" prefix. (We will also ensure that every class of Spec started with the same prefix for consistency). For extensions methods, we will rename them to have a version different from Spec 1 (The spec from Pharo 7). Once done we will integrate this new version in Pharo 8. From there we will wait some weeks to let users who started to use the updated Spec change their projects to use this new Spec2. Finally, we will revert all changes that happened on Spec 1 and deprecate the packages. We hope this will make things easier for everyone. Have a nice day! -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] FW: Versioning with Iceberg
On Sat, Jun 1, 2019 at 10:42 AM Stephan Eggermont wrote: > > ducasse wrote: > > Now migrating to iceberg is super easy and configurations are a lot > > simpler than with monticello. > > Could you explain how configurations are simpler? Configurations were managing project versionning and project dependencies while baselines are only managing the dependencies since the project versionning is done by git with it commit by project opposed to the commit by package of Monticello. This make configurations a lot simpler IMO. > > Stephan > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Pharo Launcher failing in Windows 10
Le 30/05/2019 à 14:43, casimiro.barr...@gmail.com a écrit : > Recently installed (clear install). > > Apparently OSPluginWrapper.dll memory faulting. > Hi, I already got this problem and the only fix I know for now is to restart the computer. It is planned to improve the system command integration of Windows but for now, nobody got the time to work on it. But it's on the roadmap. > Windows 10 64bits > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] image state saving TDD
On Mon, Apr 29, 2019 at 2:55 PM Ben Coman wrote: > > Just a thought on a dream feature... > > When doing TDD, it would be super cool if in a test method, > the state of the image was saved just before an #assert: > so if the assert fails the state is restored to just before the assert > was called, > so I don't have to and multi-step through the whole method > to get back to the message I want to step into. > Hi, This is a feature I requested for DrTest :) https://github.com/juliendelplanque/DrTests/issues/45 > cheers -ben > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] About
On Wed, Apr 10, 2019 at 1:52 PM ducasse wrote: > > Nicolas > > I tried to find the new primitive and I did not find it here > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c > > I found the old one. > Did I look in the wrong place? > If I am not wrong it is directly in Slang and will be a numbered primitive. The primitive was added in the commit Nicolas quoted but I'm not sure the registration of the primitive in the primitive table was done. > Stef > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] About
On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse wrote: > > Hi > > I recall that clement told me that returning 1,2 or 3 instead of negative, > zero, positive was slow. > And I wonder if the primitive got change to the logic clement proposed? > > Could we not introduce another primitive and use it from the image? Hi, I think Sophie already did most of the work to introduce a new primitive. The missing steps to use the new optimized way to compare strings are: - Add the primitive to the primitive table VM side for Pharo/Squeak and Newspeak - Use the new primitive in the image and call this one for string comparison With this new primitive performances on string comparison can be improved around x2.5 to x5 times faster. > > compare: string1 with: string2 collated: order > "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating order > of characters given by the order array." > > | len1 len2 c1 c2 | > > > > > > len1 := string1 size. > len2 := string2 size. > 1 to: (len1 min: len2) do: > [:i | > c1 := order at: (string1 basicAt: i) + 1. > c2 := order at: (string2 basicAt: i) + 1. > c1 = c2 ifFalse: > [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]]. > len1 = len2 ifTrue: [^ 2]. > len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3]. > > > Stéphane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] how implement isAbstract?
Le 30/03/2019 à 19:35, Denis Kudriashov a écrit : > Hello. > > We did recently several cleanups by marking abstract classes as abstract > using #isAbstract method > (https://github.com/pharo-project/pharo/pull/3087, > https://github.com/pharo-ide/Calypso/pull/462) > . > > I would like to discuss here and decide what the right way to implement > this method. > > The logic behind is to only return true when receiver is defining class > of this method. And it should be false for any subclasses (if they do > not implement own #isAbstract method). > > There is old pattern for implementation to compare name of class: > > MyAbstractClass class>>isAbstract > ^self name == #MyAbstractClass > > > It is used in many places (mostly tests). And it was used in recent > Pharo PR (3087). > > We have another pattern in other places which simply compare self with > class: > > MyAbstractClass class>>isAbstract > ^self == MyAbstractClass > > > And in Calypso I used "more simplified" version using equality: > > MyAbstractClass class>>isAbstract > ^self = MyAbstractClass > > I think we would all agree that simplest version is last one. It does > not raise any question about why we compare name or why we use identity > comparison. So this is my choice in this discussion. > > Please write arguments about your preferred implementation. And let's > choose single way at the end. There is an idea to add a command into > browser to make classes abstract. And this decision will be used as a > template. > > Hi, Personally I always used the last one. (self = MyAbstractClass) At first it is because it's the first implementation I saw. Then later, after seen the other two, I sticked with this one because it seems to be the simpler for me and I like my code to stay the simpler possible if there is no problem with that. Until now I never got a problem with this implementation. > Best regards, > Denis > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
[Pharo-dev] Variables in auto-completion
Hi, I remember that in old Pharo versions, the auto-completion added the variables at the top of the completion list. Now they are at the bottom under the classes. The original version worked better for me. The current version really annoys me since most of the time I would prefer to have a variables completed. Is there a setting somewhere to get the old behavior back? If not, does someone knowing the implementation of the auto-completion knows where I could put a metalink to get the old behavior back for me? -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] Host window icon
Hi, Currently, the CI of Pharo has two non random test failures. windows-32 / Tests-windows-32 / testHostWindowIcon – Windows32.Graphics.Tests.Primitives.DisplayScreenTest windows-32 / Tests-windows-32 / testHostWindowIconWrongTypeOfArgument – Windows32.Graphics.Tests.Primitives.DisplayScreenTest I know this was a part of the system was improved during Pharo 7 to be able to display a custom icon at the top of the window. Does someone knows why it is failing? Or should we investigate? -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Using Metacello scripting API with non-github repo
On Tue, Feb 19, 2019 at 2:57 PM Sven Van Caekenberghe wrote:
>
> Hi,
>
> My code lives in a private bitbucket git repo, how can I use this with the
> Metacello scripting API ?
>
> Metacello new
> repository: 'ssh://g...@bitbucket.somehost.be:8899/xxx/t3-pharo.git';
> baseline: 'BetaNineT3';
> load: #('core' 'gb').
>
> IOW, what is the correct URL ?
>
> Is that even possible, if not what is the alternative ?
>
> I created/used this repo before, using keys as authentication.
>
> Could one also use username/password authentication, like when deploying ?
Hi,
I think non default ssh port will not be supported by Metacello.
I had to add it for gitlab to be able to reference repositories from a
self hosted gitlab with non default ssh port. I guess the same can be
done for bitbucket but it I doub it's already done.
For Gitlab I added it in MCGitlabRepository for the Metacello part and
in the Iceberg extensions of this class to use the new infos in
Iceberg. (Method scpUrl)
>
> Sven
>
>
>
--
Cyril Ferlicot
https://ferlicot.fr
Re: [Pharo-dev] File problems in Pharo 8
Le 12/02/2019 à 18:56, Alistair Grant a écrit : > Hi Cyril, > > I'm glad you're able to commit now. :-) > > A few comments on the performance: > > I haven't done a performance comparison for a while, and there have been > a few changes in the plugin, so I'll keep it qualitative for now and try > and run some more tests soon. > > FileReference>>exists should be significantly faster than before. It > used to retrieve all the file attributes (an array of values, mostly > integers and booleans). Now it just returns a boolean. > > Retrieving individual file attributes should also be faster. E.g. > FileReference>>modificationTime also retrieved all file attributes and > threw away everything except the desired attribute. Now it answers just > the requested attribute. > > Retrieving a file entry, i.e. DiskDirectoryEntry, is probably a bit > slower because more information is being retrieved than previously. > > FileReference>>exists gets called a lot. So do requests for individual > file attributes. So my perception was that overall the system would > probably be a bit faster than previously. > > However any application that iterates over a large number of files could > well be slower because the Guide / Visitor system retrieves entries. > Thank you for the detailed explanation! > Do you know how many files are being deleted when the system feels > slower? I was committing in Iceberg that is a Filetree repository. My change impacted multiple package thus I would say it should be around 2500 files and 500 folders. > > It would be straightforward to modify the directory iteration primitives > to only answer the file name instead of all attributes. I'll have a > look and see how easy it would be to modify the Guide / Visitor objects > to retrieve only file names instead of entire entries. > So if possible it would make file copy/deletion even faster than before IIUC? That would be really great! > Cheers, > Alistair > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] File problems in Pharo 8
On Tue, Feb 12, 2019 at 11:47 AM Alistair Grant wrote: > > Hi Cyril, > > In not at my PC at the moment, sorry. > > Can you try with vmLatest80? > > curl get.pharo.org/64/vmLatest80 | bash > > This looks like an issue I resolved recently. > I can commit with this vm. Thank you. I have the impression that the commit takes longer now but I don't have any bench. (maybe it's just my imagination). > > Cheers, > Alistair > (on phone) > >> -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] File problems in Pharo 8
Hi, In Pharo 8 I have troubles because I get an error each time I try to do an action calling a #deleteAll. I think the problem might have been introduced by the changes on Files that were done to introduce FIleAttributes. I don't have much knowledge on this area and this is a little blocking for me because when the problem triggers I cannot commit my changes with Iceberg since it needs to delete folders. Bug report: https://github.com/pharo-project/pharo/issues/2495 -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] ConfigurationOfGrease for Pharo8
On Sun 3 Feb 2019 at 19:20, Alistair Grant wrote: > Hi All, > > It looks like Grease is still hosted on smalltalkhub - if not, please > let me know where. > Hi, Here: https://github.com/SeasideSt/Grease :) > Are there any objections to me updating > ConfigurationOfGrease>>release1: to load on Pharo8? > > The updated method is (apologies for loss of formatting): > > release1: aSpec > > aSpec for: #'pharo3.x' version: #'release1.3'. > aSpec for: #'pharo4.x' version: #'release1.3'. > aSpec for: #'pharo5.x' version: #'release1.3'. > aSpec for: #'pharo6.x' version: #'release1.3'. > aSpec for: #'pharo7.x' version: #'release1.3'. > aSpec for: #'pharo8.x' version: #'release1.3'. > aSpec for: #'squeak5.x' version: #'release1.3'. > aSpec for: #'gs3.x' version: #'release1.3'. > aSpec for: #'pharo1.x' version: #'release1.2'. > aSpec for: #'pharo2.x' version: #'release1.2'. > aSpec for: #'squeak4.x' version: #'release1.2'. > aSpec for: #'gs2.x' version: #'release1.2' > > The change is the addition of the #'pharo8.x' line. > > Thanks, > Alistair > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [ANN] Pharo open documentation
Le 30/01/2019 à 21:25, Hernán Morales Durand a écrit : > Hi Cyril, > > Nice project! > I think you forgot to add the URL : > https://github.com/pharo-open-documentation/awesome-pharo > > Note: the Zinc entry has a reference to Cytoscape.js? > Good catch! Just an error of copy past when I reorganized the entries :) It should go at the end of TelescopeCytoscape line. Thank you. > Cheers, > > Hernán > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
[Pharo-dev] [ANN] Pharo open documentation
Hi everyone! With some other members of the community we are proud to announce a new effort on Pharo documentation. We launched an organization pharo-open-documentation which is a user-maintained documentation related to Pharo environment, language, and libraries. Currently it has three main projects: - pharo-wiki : Wiki related to the Pharo programming language and environment. - awesome-pharo : A collection of awesome Pharo libraries, tools, frameworks and software. We want to make this project a reference in https://github.com/sindresorhus/awesome - awesome-pharo-ml : List of projects, books, booklets, papers, and applications related to machine learning, AI, data science in Pharo. Contributions are welcomed! If you own a cool project in Pharo others could use in their own projects, send us a PR to awesome-pharo! If you have knowledge on Pharo or projects of Pharo, we would be glad if you could contribute to the pharo-wiki! Don't forget to read the contribution guidelines. ;) We opened a Twitter to announce new entries on the pharo-wiki. https://twitter.com/PharoOpen Have a nice day! -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Contribute to pharo8.0 ?
Le 29/01/2019 à 23:47, Sven Van Caekenberghe a écrit : > Hi, > > I am trying my first contribution / PR to pharo8.0 > > I started with a latest zeroconfig 8.0 image/vm and I deleted my old fork and > made a new one. > > But repairing the repository by fetching does not bring it to the detached > state > Hi, There is currently a bug eating one character of the commit hash. So Iceberg does not find the hash and thinks we need a fetch. So currently we need to checkout Pharo8.0 in order to be in a good state :( > I also don't understand how to make an issue branch for > > https://github.com/pharo-project/pharo/issues/2395 > > Is it Iceberg > Pharo > Create new branch for issue or Iceberg > Github > > Create new branch for issue ? Just create a branch and choose the option to create a branch from a Github option. The other one was for Manuscript and is now useless for Pharo 8. I opened an issue in Iceberg to remove it but I did not got the time to contribute the change. > What is the difference ? > What about the Remote ? > Can I work with only an issue on GitHub ? > Yes! What I am doing currently: - Open an issue XX - Sync my fork Pharo8.0 branch via command line (This is optional and can also be done in Pharo. I just do it via command line because I like it better that way) - Download a Pharo 8 image - Checkout the Pharo8.0 branch to get in a clean state because of the hash eating bug I mentioned earlier - Create a new branch from a github issue of the pharo remote - Do the changes and commit. I add `Fixes #XX` in the commit message to close automatically the issue when the PR is merged. - Push to my remote - Open a PR against Pharo8.0 through Iceberg > GitHub > Create new pull request > Is the documentation > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > really up to date ? > No We should correct the hash eating bug before updating it I think. > Sven > > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Bad baseline practices
On Wed, Jan 16, 2019 at 9:59 AM Norbert Hartl wrote: > > > > > > > In a plain Pharo 7 image > > > > BaselineOfCalypso > > BaselineOfCommander > > BaselineOfSystemCommands > > In which version? Because in the latest I do not see any floating version. I know that Denis uses floating version but only for the development version, not for release. > > Stephan > > > Wasn’t the problem that the wildcard notation is likely to hit the github API > request limit? > No, Denis is uring branches name v0.9.x for example to not use tags. > Norbert > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] wish for p8: parserewriter UI
Le 15/01/2019 à 20:25, Stéphane Ducasse via Pharo-dev a écrit : Wasn't it the work of Mark Rizun? -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Bad baseline practices
On Tue, Jan 15, 2019 at 6:03 PM Stephan Eggermont via Pharo-dev wrote: > > > > I’m not sure why, but I’ve noticed baselines being changed to refer to > patch versions for releases. Why are the old configuration problems > repeated? Which project are you talking about? > > Stephan > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Managing of P7/P8
On Tue, Jan 15, 2019 at 4:38 PM Torsten Bergmann wrote: > > Hi, > Hello, > as Pharo 8 development started I wonder: > > 1. When will it be possible to already get a Pharo 8 latest image > from ZeroConf. Because one requires ideally the latest image to > contribute > - no? > I guess zeroconf for P8 will be set after Pharo 7 release. For now I get manually a Pharo 8 image from files.pharo.org and I use the Pharo 7 VM to contribute. > Or should one search/download from the CI server for the time being > (which > would be cumbersome) > > 2. How will contributions still going to P7 handled regarding P8. > Typically a bugfix for P7 should also go into the P8 image - no? > But from the integration mails floating around I do not see > this is happening. > There is only few fixex that will still be integrated in P7 for the release. While the Pharo 7 development is still active there is often a merge of the P7 branch in the P8 branch to keep them up to date. After P7 I guess backported issues will be integrated in the P7 and P8 branches. > I would expect that a PR for Pharo 7 would also be merged into Pharo 8 > branch. > If not the images could easily diverge too much or done fixes for P7 > will not be in P8. > > Thanks in advance for clarification! > > Bye > T. > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Is metacello aware of MC branches???
On Fri 11 Jan 2019 at 22:51, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > Thanks, > that did not work, but I think my mistake was to write this; > > spec for: #'pharo6.0.x' > > instead of: > > spec for: #'pharo6.x'. > > Smalltalk version -> 'Pharo6.0', so probably the second dot does not match > anything... > I'll have to review more ConfigurationOf... > >> Hello, I do not have an image to check but you can find compatible by executing something like `Smalltalk metacelloPlatformAttributes` in a Pharo 6 image. >From what I wrote here: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md#loads-different-packages-depending-on-the-pharo-version I guess your problem is that you tried to load the code in Pharo 6.1 and not 6.0. >>> -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] Rewrite system of critics
Hi, I am investigating a bug in critics. https://pharo.fogbugz.com/f/cases/22250/RBCascadeNextPutAllsRule-refactoring-crash-BlueInk I found the source of the problem. In Pharo 6 this critic did a rewrite of the method using RBParseTreeRewriter. This one managed the case where the refactored node was contained in a cascade or not. In Pharo 7 the rewrite is done in ReReplaceNodeCritique. But this one uses a becomeForward: to replace an old node by a rewritten node. But this breaks in case the new node cannot just replace the old one, like when it try to introduce a cascade in another cascade. I don't know renraku enough to fix the problem and I was wondering why ReReplaceNodeCritique does the replacement itself when we already have RBParseTreeNode? -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Happy new year!
--- Begin Message --- On Mon, Dec 31, 2018 at 7:02 PM Esteban Lorenzano wrote: > > Hi list, > > Just that. > I wish you all have a happy new year, and may it be even better than this one > :) > Happy new year everyone :) > Esteban -- Cyril Ferlicot https://ferlicot.fr --- End Message ---
Re: [Pharo-dev] Downloading file with Zinc
On Thu 20 Dec 2018 at 21:00, Stephane Ducasse wrote: > Hi Sven > > I would like download files (pdf) with Zinc (not opening them in Pharo). > I wonder how I can do it with zinc. > Hi, Here is a snippet with a progress bar if you want to give feedback to the user: https://github.com/Metacello/metacello/blob/master/repository/Metacello-Platform.pharo60.package/MetacelloPharoPlatform.class/instance/downloadZipArchive.to..st > Tx > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Pharo & Windows 10
On Sat 15 Dec 2018 at 15:12, Tudor Girba wrote: > Hi, > > Where is the PR? > Hi, https://github.com/pharo-project/pharo/pull/1985 I guess it’s this one. > Cheers, > Doru > > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Pharo & Windows 10
On Fri 14 Dec 2018 at 23:22, John Brant wrote: > Is anyone using a recent Pharo with Windows 10? I'm using > Pharo-7.0.0+rc1.build.44.sha.d3be1c018447fa5f7ba666cea7aff396f36d4309 > (64 Bit) and am getting crashes whenever I try to commit anything using > Iceberg. This seems to be a recent issue -- if I open an image from a > few weeks ago, it works. Hello, I think this is a known issue on the 64bits Windows version. It’s one of the remaining issue before releasing a stable version of Pharo on Windows 64bits. Thank you for the report! > > Also, when I reopen the image, and the try to open the "Code Changes" it > fails with: > > GrafPort(Object)>>error: > GrafPort(BitBlt)>>copyBits > GrafPort>>copyBits > GrafPort>>image:at:sourceRect:rule: > FormCanvas>>image:at:sourceRect:rule: > FormCanvas(Canvas)>>drawImage:at:sourceRect: > FormCanvas(Canvas)>>drawImage:at: > HiRulerBuilder>>form > HiRulerController>>buildRulerForm > HiRulerController>>refreshRuler > HiRulerController>>values: > HiRulerController>>updateFromTree > [ hiedraRulerController updateFromTree ] in > EpLogNodeGraphPresenter>>initializeHiedraController in Block: [ > hiedraRulerController updateFromTree ] > BlockClosure>>cull: > BlockClosure>>cull:cull: > BlockClosure>>cull:cull:cull: > BlockClosure>>cull:cull:cull:cull: > [ :announcement :ann | > aBlock > cull: announcement newValue > cull: announcement oldValue > cull: announcement > cull: ann ] in CollectionValueHolder(Model)>>whenChangedDo: in > Block: [ > :announcement :ann | ... > BlockClosure>>cull:cull: > [ action cull: anAnnouncement cull: announcer ] in > AnnouncementSubscription>>deliver: in Block: [ action cull: > anAnnouncement cull: announcer ] > BlockClosure>>on:do: > BlockClosure>>on:fork: > AnnouncementSubscription>>deliver: > [ "Ensure delivery to remaining announcements" subscription deliver: > anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in > Block: [ "Ensure delivery to remaining announcements" sub...etc... > BlockClosure>>ifCurtailed: > SubscriptionRegistry>>deliver:to:startingAt: > SubscriptionRegistry>>deliver:to: > SubscriptionRegistry>>deliver: > Announcer>>announce: > CollectionValueHolder(NewValueHolder)>>valueChanged: > > This issue existed in the image I have from a few weeks ago. > > I've tried using the latest vm's from both files.pharo.org and bintray.com > . > > > John Brant > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Anyone else seen crashes like these ?
On Mon, Nov 12, 2018 at 2:37 PM Sven Van Caekenberghe wrote: > > Hi, > > I run Pharo 7 64-bit on a macOS laptop, where the images are kept running > across sleep/wake cycles. > > For many weeks, it often happens that an image crashes before/after such a > sleep/wakeup (not all the time, just regularly). > > Here is a crash dump from today (fresh image/vm from WE, nothing special > loaded). > > Related to scheduling ? Event handling ? > Hi, I switched to an macOS at the beginning of October and since I often have this kind of behavior. > > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] [ANN] Iceberg v1.4.0
Hello! This week we are releasing the version v1.4.0 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.4.0) This version is available in the latest Pharo 7. This release fixes a bug introduced in v1.3. It also add new features in the repository view, add some cleaning and also re-introduce a feature that was lost. Thanks to all contributors. Enjoy! Full changelog: Bugfixes #1068 'There is no associated repository configured.' warning on right clicking missing repository Features #1077 Repository view: Allow to collapse branches/remotes/tags trees #847 Move tags under remotes in Repository view #1070 set upstream if missing Cleanups #1066 Pharo 7: PackageManifest subclasses should be packaged with "Manifest" #1015 Replace usages of Glamour in the Github Plugin #1063 1061-Introduce-iconNamed-in-IceDefinition-and-IceTipModel-and-remove-all-the-terrible-Smalltalk-ui-icons -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [ANN] Iceberg v1.3.1
On Mon, Nov 5, 2018 at 5:09 PM Hernán Morales Durand wrote: > > Hi Cyril, > > Does the update apply to Pharo 6.1? > Hi, The version will not be present by default in Pharo 6.1 because it cause too much changes to be in a minor release. (The last Iceberg release in Pharo 6.1 was the 0.6 or 0.7 I think). But it can be loaded via the script in the README. > Cheers, > > Hernán > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] [ANN] Iceberg v1.3.1
Hello! This week we are releasing the version v1.3 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.0 +https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.1) This version will be available after we merge this PR: https://github.com/pharo-project/pharo/pull/1951 This release contains some new features such as the support of self hosted gitlab, integration with github, etc. It also contains multiple bug fixes, cleanups and enhancements. On the CI part, Guille made the Appveyor build green! This will increase the stability of the windows support. Thanks to all contributors. Enjoy! Full changelog: Features #1021 Self hosted gitlab support #1027 Improved new tag dialog to generate semantic versionning tags #1044 Show a button "View on Github" when creating a PR #1008 Add "create branch from GitHub issue" option #1048 Add commands to open remotes on Github #1010 Add menu entry in extras to force calculate diff Bug corrections #975 Metacello asks too many times what to install when there are conflicting versions #980 Iceberg should Identify better the packages and the normal files #982 The Edit Project should have a Warning if it will affect the packages #986 Iceberg does not realize changes in extended classes #999 Pulling and pushing to a gitolite server asks password #984 Conversion to Tonel generates corrupted .properties #1041 Filter in repository view don't work with capital letters #1019 Metacello Integration leaves Monticello leftover repositories #859 Creating a branch and pushing does not sets the upstream #1043 Packages starting with lowercase not recognized #991 Error on right click in the project editon wizard #775 Reviewing a PR is broken #1036 Debugger if we try to merge without selecting a branch #1064 Fix failing tests regarding clean code in Pharo Enhancements #988 Iceberg should load the packages in a single MCLoader (This will make the loads of packages atomic) #1001 Use "instance creation" instead of "instance-creation" for method protocol name #1004 Use displayScaleFactor in UI #977 Add ToolTip help to the Commands #1030 Better support for binary files #1034 SSH passphrase is now hidden Cleanups #1018 Iceberg UI relies on deprecated classes from Spec and Commander #1051 Clean useless huge hierarchy in Github plugin UI Infrastructure Enhancements #1023 Fix CI for windows -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] GitHub Topics
On sam. 13 oct. 2018 at 10:42, Norbert Hartl wrote: > I don‘t want to kick off another war but shouldn‘t we add pharo as a > language to github. Now it is a topic but the configurations for linguist > are still tying it to smalltalk. > > Norbert > > > Hi, Linguist find the language based on theee things: - what is written on the .gitattribute file - the extension of the file - the source code (it compares it with examples) Since multiple Smalltalk shares FileTree format and Tonel format, the extensions and source code will be the same for Pharo and other Smalltalk. Introducing a "Pharo" language would force everyone to add a .gitattribute file to their project, and I'm sure not that many people will do it. -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] STON updates/improvements
On ven. 12 oct. 2018 at 11:38, Sven Van Caekenberghe wrote:
> Hi,
>
> I have consolidated all repositories where STON code lives so that they
> are now all in sync, and in sync with changes from Pharo 7.
>
> http://ss3.gemtalksystems.com/ss/STON/
> http://smalltalkhub.com/mc/SvenVanCaekenberghe/STON/main/
> https://github.com/svenvc/ston
>
> There are 2 CI builds
>
> https://travis-ci.org/svenvc/ston
> https://ci.inria.fr/pharo-contribution/job/STON/
>
> The project's format will remain FileTree (until Tonel is supported on
> other Smalltalk implementations).
>
>
> Last week I applied a couple of changes that I wanted to apply for a long
> time.
>
> Traits are no longer used in the implementation (which should help porting
> to other Smalltalk implementations).
>
> More specifically the following are used (again)
>
> - Class>>#stonOn:
> - ClassDescription>>#stonContainsSubObjects
> - Metaclass>>#stonName
> - Metaclass>>#stonOn:
>
> instead of
>
> - TClass>>#stonOn:
> - TClassDescription>>#stonContainsSubObjects
> - TApplyingOnClassSide>>#stonName
> - TApplyingOnClassSide>>#stonOn:
>
> use #instanceSide instead of #theNonMetaClass in MetaClass>>#stonOn:
>
> Reorganised the packages with sub tags.
>
> Add support for Fraction and ScaledDecimal literals (not in JSON mode).
> Previously a float conversion meant there was a loss of information.
>
> Change the representation of Date to include a timezone offset (since the
> current Date implementation is sensitive to this).
>
> 2018-10-11Z
> 2018-10-11+00:00
> 2018-10-11+02:00
>
> A missing timezone offset is interpreted as being the local timezone
> offset.
>
> Add more special representations for common value style objects. One of
> STON's goals is to be a human readable and human editable representation of
> an object graph while remaining 100% correct (not losing information). The
> following were added for this reason:
>
> MimeType and URL using ZnMimeType and ZnUrl respectively as simplified
> values.
>
> MimeType['application/json']
> URL['https://pharo.org']
>
> Color
>
> Color[#red]
> Color{#red:1.0,#green:0.0,#blue:0.0,#alpha:0.4}
>
> FileReferences to the DiskFileSystem (effectively normal files)
>
> FILE['/tmp/foo.txt']
>
> Here is an example of how much difference that makes. Given the following
> Dictionary
>
> {
> #background->Color red.
> #workdir->'/tmp/pharo/work/' asFileReference.
> #home->'https://pharo.org/experimental' asUrl.
> #datatype->'application/json' asMIMEType } asDictionary
>
> Which contains real objects as its values.
>
> was serialised by STON BEFORE the changes as
>
> {
> #datatype : ZnMimeType {
> #main : 'application',
> #sub : 'json'
> },
> #background : Color {
> #rgb : 1072693248,
> #cachedDepth : 32,
> #cachedBitPattern : Bitmap [
> 4294901760
> ],
> #alpha : 255
> },
> #home : ZnUrl {
> #scheme : #https,
> #host : 'pharo.org',
> #segments : OrderedCollection [
> 'experimental'
> ]
> },
> #workdir : FileReference {
> #filesystem : FileSystem {
> #store : MacStore {
> #maxFileNameLength : 255
> }
> },
> #path : AbsolutePath [ 'tmp', 'pharo', 'work' ]
> }
> }
>
> which is 100% correct, but not very human friendly.
>
> Now, AFTER the changes, the STON serialisation looks as follows:
>
> {
> #datatype : MimeType [ 'application/json' ],
> #background : Color [ #red ],
> #home : URL [ 'https://pharo.org/experimental' ],
> #workdir : FILE [ '/tmp/pharo/work' ]
> }
>
> which is a huge improvement, IMO.
>
> What do you think ? Comments, feedback, remarks ?
> Any other suggestions for other object that could use this treatment ?
>
This is great thank you! In some projects I had some hacks for the export
of FileReferences in a readable way, it is great to know have a readable
export by default in ston.
> Sven
>
>
> --
Cyril Ferlicot
https://ferlicot.fr
Re: [Pharo-dev] GitHub Topics
On Mon, Oct 8, 2018 at 11:32 AM Sven Van Caekenberghe wrote: > > One of the goals of moving to GitHub.com is to gain visibility. > > There is https://github.com/topics > > I think we should standardise how we tag our projects. > > So at least 'Pharo' (capitalised) should be there. > > Do we also add 'Smalltalk' by default ? > > Any other suggestions, ideas ? > Hi Sven, I think topics are case insensitive. Personally I tagged all my projects with "pharo" and "smalltalk", then I add tags depending on the subject of the project. > Sven > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] ZipArchive and symbolic links
Hi! I just found that ZipArchive does not honor symbolic links (at least in Pharo 7). I would like to know if this is a known bug? I found out because I was using Pharo to unzip some Pharo vms and it broke all the dynamic libraries :( -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Release test for unused temps and other
Le 06/09/2018 à 17:50, Torsten Bergmann a écrit : > Hi, > > the very nice contribution on GIFReadWriter/animated images (see > https://pharo.manuscript.com/f/cases/22137) > unfortunately introduced some methods that had no sender, were uncategorized > and had unused temporary variables, etc. > > Something that is meanwhile shown by our tools and easy to fix. I guess it > was some overseen leftover. Unfortunately this > also slipped through the integration process as it was merged without an > approval from a community reviewer. > > I dont want to lament too much on this specifc case (especially as I now > fixed it in https://pharo.fogbugz.com/f/cases/22426). > > But after I cleaned the P7 image this spring to not have unused temporaries > anymore I was suprised to find such > glitches again now. So to me it shows that we need to write more tests to > detect violations and keep our achieved quality standards > up and also should not solely rely on the review process. > > Otherwise we need to invest our time in cleaning up our own stuff afterwards > again and again. > > To be specific one can evaluate: > > CompiledMethod allInstances select: [:m | m ast temporaries anySatisfy: > [:x | x binding isUnused ]]. > > to find unused temps - which would be easy to package up into one of the > release test to ensure no unused temp vars are left > (the tearDown would require an "ASTCache reset"). > > The problem is that this simple test would take around 20-30 seconds > depending on machine and I do not know if it would be a > good idea/good solution to integrate. Especially I'm not sure if it is worth > the issue or will kill the CI again and again. > > What do you think about it? Comments appreciated? > Hi, Maybe we could have a package with release tests that are not executed by the CI but that are executed at the moment of the feature freeze and some time before the Pharo release to ensure the quality of the code base for tests that are too long? > Thanks > T. > > > > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Auto-completion of methods names
Le 05/09/2018 à 10:00, Marcus Denker a écrit : > > I will add a simpler version by default back (today). > > The old version tried to be clever and replace whole methods… which was > extremely confusing (and not really > helping). It complicated the model, too. > (We got even bug report > > Method name completion is nice, it is very easy to add method name completion > back, I will do it today. > Great, thank you! I'm glad that it's not just a feature removal without replacement :) > Marcus > > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
[Pharo-dev] Auto-completion of methods names
Hi, Today I tried to launch a Pharo 7 image and I just saw that one of my setting was failing. The setting is from NEC and allow to auto-complete the method name and could be enable like this: NECPreferences overrideModel: true In the recent Pharo 7, #overrideModel: and all the code depending on it was removed. Is there an other way to get this feature or will it just be removed totally from Pharo 7? -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1
Le 24/08/2018 à 19:03, Sean P. DeNigris a écrit : > Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the > following: > <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> > > This seems to usually signal that a crash is not far away. It's doubly > concerning because there is no clear way to stop the troubled process > (interrupts often bring up a debugger on something else) and because, since > one is now unable to save any code, it's unclear how to start over easily in > a new image. In an extreme scenario, I recently panicked during such an > experience and accidentally clicked "Save" instead of "Save As…" resulting > in an image that took hours worth of code (I know maybe not a great > practice) with it to the grave. > > Any idea why this happens or what we might be able to do anything about it? > > p.s. I was so concerned that I immediately resolved to move to Pharo 7, but > that turned out not to be an option do to the recently reported bug with > extension methods (that don't exactly match the package name) > > Hi, IIRC the problem only happens when the commit windows is maximize. Something happen, maybe the progress bar updating launch a redraw of the morph, and if the iceberg window is under the progress bar it also try to redraw it but for that it snapshots methods etc... When I did not maximized my windows and kept them in the center it was fine. > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Win10/Launcher/Pharo7.1122--ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?)
Le 11/07/2018 à 19:35, Ben Coman a écrit : > I just just downloaded and installed the latest PharoLauncher > and running build 7.1122. > > After enabling Custom SSH Keys and opening Iceberg, > doing "Repair repository" on "iceberg" repo, > clicking "Clone again this repository" > Clone from github > Owner name: pharo-vcs > Project name: iceberg > Source directory: (blank) > Protocol: SSH > > after downloading 9.4MB over 6632 files > I get an error... "ZdcPluginMissing: SSL/TLS plugin initailization > failed (VM plugin missing ? OS libraries missing ?)" > > > Can anyone corroborate or see anything obvious I've done wrong? > Hi, Can you check that you have the SqueakSSL.dll DLL with your VM? I had the problem already that Windows Defender consider it as a maleware and delete it during the unzip of the VM. > > Image > - > C:\PharoLauncher\images\Exercism(71122)32bit-testing\Exercism(71122)32bit-testing.image > Pharo7.0alpha > Build information: > Pharo-7.0+alpha.build.1122.sha.9d8389221ee7e9c58d664a388fae86511c02edf7 > (32 Bit) > Unnamed > > Virtual Machine > --- > C:\PharoLauncher\vms\70-x86\Pharo.exe > CoInterpreter VMMaker.oscog-eem.2265 uuid: > 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > Win32 built on Aug 27 2017 20:40:46 GMT Compiler: 5.4.0 > VMMaker versionString VM: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug > 27 21:55:26 2017 +0200 $ Plugins: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > CoInterpreter VMMaker.oscog-eem.2265 uuid: > 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > > Windows 10 > > cheers -ben > > P.S. I tried deleting the the Pharo 7 VM and having it download a new one, > but I get... > Error downloading 'https://files.pharo.org/get-files/70/pharo-win-stable.zip' > I haven't looked into that yet. Got to head to bed. > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] Problem with zinc 2.9.2
> Need to investigate more. There are two .15 versions but there is 1 year > in between (if you didn’t notice TheIntegratior.15 is from 2017). Just want > to have more context information because I can only see that this is > strange but lacking insight. > > I’m trying to figure out why it does not update Zinc-FileSystem. No matter > what I do I cannot get Metacello to load the newer package. That would fix > the issue because I’m loading 2.9.2 which should have > Zinc-FileSystem-SVC.15 and not stay on the one included in the image. > > I think this is important for everyone that has a product based on 6.1 and > that want to migrate someday to pharo7. This way it is impossible to do it > step by step. If there is a package .15 in the image and a package .15 in the repo, I think Metacello will not update because it rely on the numbers to know when to update. If it find a .15 and currently have a .15 I think Metacello will think they are at the same version. > > Norbert > > > > > > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Commenting test classes?
Le 04/07/2018 à 00:39, Tim Mackinnon a écrit : > Au contraire - when looking at a Test - seeing inline the comment of the > class to remind me what I’m supposed to be testing is actually quite > helpful. I fully expect this is where GtDocumentor is going to take us > (if we integrate it into our tools) - letting us inline things so we > don’t have to go and hunt them out. > > In general most of my tests classes are here to test one class, then the name is "NameOfMyClassTests". In that case there is no need for a comment like "I am a test class for NameOfMyClass". I comment tests classes only when it's more functional tests and that they cover a part of the system. But I don't want to have to add comment such as "I am a test class for NameOfMyClass" for the vast majority of my test classes. -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] [CI] Cause of the random failures in the CI
On 19/06/2018 17:02, Alistair Grant wrote: > Hi Cyril, > Great work! > Thank you. Also thanks to Guille, Vincent, Marcus that helped to find the problem. > It would be nice if all the temporary files were in a single folder. > Cleaning the environment then becomes a matter of deleting that one > folder. (At the moment, there is a vm installed in to the root > directory, a vmtarget directory (I'm guilty here) and > bootstrap-cache). > Maybe yes :) > Slightly off-topic, but I'm also wondering why the test scripts > download the VM again? Why not just use the one that is already in > vmtarget? > Because it is a vm linux and tests are executed on OSX and Windows too. > > > This definitely helps :-) > > > Thanks, > Alistair > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] [CI] Cause of the random failures in the CI
Hi, Since months now there are a lot of random failure on the CI making it hard to work. There is different kind of failures: - Network problems - Failing tests - Incomprehensible problems Now I don't see much failure due to Network. I suppose the Inria infrastructure improved. Failing tests were corrected those past months and we see less and less of them. Now the big problem are the incomprehensible crashes such as "The workspace was not found" or "FileDoesNotExistException" or "pharo-vm/ is already present". We just found the problem :) During the validation of the Bootstrap multiple tests are launched on OSX/Windows/linux in parallel. Each task is on a different slave of the Jenkins. But, apparently we discovered that two slaves could have the same disk. Usually it does not cause any trouble since a job is only run by one slave. But in this particular case, two slaves can be used by the same job and mess with the resources of each other. We highlighted the problem by adding logs to the CI. Now when we launch tests we create a file with the name of the task. Today we got a crash and in the log we see that the same workspace has two of those files, proving that they are executed on the same disk, in the same folder : […] -rw-rw-r-- 1 ci ci0 Jun 19 16:01 Kernel-tests-unix-32 […] -rw-rw-r-- 1 ci ci0 Jun 19 16:01 Tests-unix-32 As a solution we will execute the tests inside a subfolder with the name of the task and it should reduce a lot the number of problems. Have a nice day :) -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Debugger Button Positioning
Le 14/06/2018 à 20:13, Eliot Miranda a écrit : > Hi All, > Hi, > I've been using Pharo intensively for the first time, Pharo 7. > Forgive me for starting with a complaint, but I don't have time to state > all the things that are great about it; you already now ;-) > No problem. It's always easier to talk about the bad things than to good ones. :) I hope you will like your usage of Pharo. > One thing I find painful is the positioning of the debugger > into/over/through buttons. Because these are above the context list, > and you read the code like I do, one has to mouse further to reach > them. I find my focus is on the highlighted method, and my cursor is > typically within it (I'm dong implementors, or senders, or just looking > at the code). Further, there's lots of space between the Source tab and > the "Where Is?" and "Browse" buttons. Doesn't it make more sense to put > the into/over/through buttons between the Source tab and the "Where Is?" > button? If not, doesn't it make sense to put a copy of the buttons > there where they're in much easier reach? > It was raised many times before but apparently it was not easy to change. Peter did some scripts to change it and I currently use them. The code can be found here: https://github.com/jecisc/pharo-scripts/tree/master/settings/PharoSettings5.package There are some extensions to the debugger and to replace the current behaviour of the debugger I use Metalinks (https://github.com/jecisc/pharo-scripts/blob/master/settings/PharoSettings5.package/Pharo5CommonSettings.class/class/addMetaLinksForDebugger.st) If we can have a way to get it directly into the debugger it would be great. :) > _,,,^..^,,,_ > best, Eliot -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] [Ann] Iceberg v1.1.0
Le 13/06/2018 à 22:58, Sean P. DeNigris a écrit : > Ha ha, okay. > > > IIUC this is however the way people coming from the git world are used to > working (because they usually don't have awesome GUI tools/environments like > we do :) ) > I think it really depend on the IDE or tool you use. For example while I was coding in Java for the university I used Gitkraken and I never had to copy paste the URL because it has a great github/bitbucket/gitlab integration. If you connect your account it directly display the list of repo you own you and your organisations. Also when you want to add a remote it display the list of all the fork on the host. > > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] [Ann] Iceberg v1.1.0
On 13/06/2018 12:57, Tim Mackinnon wrote: > Hi I’m a bit confused by what is described below - when it says "This is > already in latest Pharo build. If you want to try it in a Pharo 6.1 ….” > - does that mean its already in the latest Pharo 7 (emphasis on 7?) > build (and I can see it in Pharo 7) - but the latest 6.1 build doesn’t > have it and you must follow the steps you described? > Hi! Each time an Iceberg stable version is released, it is integrated to Pharo 7. (Usually, it's available the next day the time to do the PR, test it, integrate it and build the new version) Pharo 6.1 is still at the v0.6 of Iceberg. IIUC, thi is mostly because the new UI depends on a lot of changes from Pharo 7 and backporting it would mean backport too many changes. The goal is to keep Pharo 6.1 as stable as possible. So the steps to update yourself Iceberg to v1.? is for Pharo 6 only. > I initially read it to mean that new Pharo 6.1 builds would > automatically get it - but that doesn’t seem to be the case? > > Tim > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Window groups and Calypso Browser
On 12/06/2018 13:41, Torsten Bergmann wrote: > Hi Denis, > > when I open a Pharo window (like Playground) and select "Create window group" > I can > drag and drop other windows onto it. So one can group several windows into > one, each > one shown with an own tab. > > This works for most of the Pharo windows (Playground, Iceberg, ...) in latest > Pharo 7 - but > not for the Calypso browser. > > I can drag a system browser into the window group - but when I drag it out > again it is just a gray > window and the content is not usable anymore. > > I guess this is a bug in Calypso - so I opened > https://github.com/pharo-ide/Calypso/issues/287 > Hi, Today I opened this: https://pharo.fogbugz.com/f/cases/22125/Cannot-drop-window-in-a-window-group-in-Pharo-7 I probably though it was broken because I tried with Calypso. > Thx > T. > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph
On sam. 9 juin 2018 at 20:22, Hilaire wrote: > > I see. > > > That way, it will be easy to change it with specific theme. > https://github.com/pharo-project/pharo/pull/1514 > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph
On 09/06/2018 16:43, Hilaire wrote: > Hi Cyril, > > From what I read in an older P7 image > DockingBarMorph>>defaultBorderWidth was not implemented, and inherited, > from AlignmentMorph which defaultBorderWidth returns 0. > It was here but in a different hook. It was in setDefaultParameters as you can see here: https://github.com/pharo-project/pharo/pull/1479/files#diff-f9fc80b09f7cbc9cb0b3f63560dabd23L613 > Next, why docking bar should have the same width as menu? > It was the previous behavior. What I changed is that now #themeChanged reset the border width to take the one of the current theme when before it was ignored. > The question is do we want docking bar to have border? > I'll probably propose a new method in the theme #dockingBarBorderWidth and we can return 0 by default for it. > I see the Playground tool bar is impacted, although it does not make is > UI less suitable. > > In the meantime I just set DockingBarMorph>>defaultBorderWidth to > returns 0, so I can use the last build at school with students. By doing > so I did not notice glitch.. > > I am not sure docking bar not having border should be considered as a bug.. > > Thanks > > Hilaire > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph
On sam. 9 juin 2018 at 09:48, Hilaire wrote: > Why ? > > DockingBarMorph>>defaultBorderWidth > ^ self theme menuBorderWidth > I found the PR I did. This code was already here but in another method. The difference is that now #themeChanged take the borderWidth into account. Before it ignored it. So it's probably that before there was a bug where the docking bar did not matched the theme for the border and it was corrected. Now, without the bug, you found that the theme was not as good as you wanted and we need to update the theme. > > Le 09/06/2018 à 09:27, Hilaire a écrit : > > I am not there yet, hope to have time. Now I just browse changes from > > github, can see several changed related to use of theme borderwidth > > -- > Dr. Geo > http://drgeo.eu > > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph
On sam. 9 juin 2018 at 09:48, Hilaire wrote: > Why ? > > DockingBarMorph>>defaultBorderWidth > ^ self theme menuBorderWidth > > > Le 09/06/2018 à 09:27, Hilaire a écrit : > > I am not there yet, hope to have time. Now I just browse changes from > > github, can see several changed related to use of theme borderwidth > Hi, This is on my todo list to check this problem. I just did not get time yet. If we revert the changes it's the menu bar that will break. I think the previous code already used the #menuBorderWidth from theme but maybe badly and it was broken? I'll check how to correct this. Maybe I'll add to the theme #dockingBarBorderWidth. But I'll probably not have the time this week end. > -- > Dr. Geo > http://drgeo.eu > > > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] The menu bar in question
On 07/06/2018 14:56, Hilaire wrote: > You should not worry about Gettext or even need it. I think Locale gets > what is needed. > The LocaleChanged event is not send when we change of translator. > Could you add settings to activate/unactivate the MenuBar? Should get in the image soon: https://github.com/pharo-project/pharo/pull/1499 > > Hilaire > > Le 07/06/2018 à 14:23, Cyril Ferlicot D. a écrit : >> There is something bad here... >> >> I see in your image that it's managed via Gettext, but get text totaly >> replace some classes of Pharo such as NaturalLanguageTranslator. >> >> Since the code is not in Pharo I can't add a system to update the >> menubar when the language changes...:( >> >> Also I see that the package "Gettext" is not in the configuration of >> gettext. In the configuration it's Gettext-Core that is loaded in the >> stable version. And this one does not replace Pharo classes. >> >> I wanted to check the version of Gettext defined in the configuration to >> see if there is the same problem but I crashed my Pharo 7 image. >> >> I can't really help more now:( I don't have the time to fix gettext. > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] The menu bar in question
On 07/06/2018 13:53, Cyril Ferlicot D. wrote: > I'm looking at this one and I would like to have more informations. > > The problem is that the menu is created before the current language is > set. So it translate in the wrong language. (It works if you do > "MenubarMorph reset"). > > I'm looking at a way to reset the menubar when the language change. > > Can you explain to me how you do to enable the translation? I never used > this feature and I don't really knows how to enable it. > > There is something bad here... I see in your image that it's managed via Gettext, but get text totaly replace some classes of Pharo such as NaturalLanguageTranslator. Since the code is not in Pharo I can't add a system to update the menubar when the language changes... :( Also I see that the package "Gettext" is not in the configuration of gettext. In the configuration it's Gettext-Core that is loaded in the stable version. And this one does not replace Pharo classes. I wanted to check the version of Gettext defined in the configuration to see if there is the same problem but I crashed my Pharo 7 image. I can't really help more now :( I don't have the time to fix gettext. -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] The menu bar in question
On 07/06/2018 10:36, Hilaire wrote: > Hi, > > I made a Dr. Geo build with today P7. > > There are several issues: > > - The menu bar items are not translated (see screenshot1) > I'm looking at this one and I would like to have more informations. The problem is that the menu is created before the current language is set. So it translate in the wrong language. (It works if you do "MenubarMorph reset"). I'm looking at a way to reset the menubar when the language change. Can you explain to me how you do to enable the translation? I never used this feature and I don't really knows how to enable it. > - The menu items does not respond, nothing happens > > - When a DrGeo window is open maximized, it is wrongly placed at 0@0, > its size is right but misplaced > (see screenshot2) > > - There are ugly frame around DrGeo menu and buttons, I don't know if it > is related to menu bar morph related modification but it's unice (see > screenshot2) > > The build can be tested at: > https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0 > > Thanks > > Hilaire > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] The menu bar in question
On 07/06/2018 10:36, Hilaire wrote: > Hi, > Hi Hilaire, > I made a Dr. Geo build with today P7. > > There are several issues: > > - The menu bar items are not translated (see screenshot1) > I'll take a look: https://pharo.fogbugz.com/f/cases/22083/Menubar-is-not-translated > - The menu items does not respond, nothing happens > This is normal for now. The Dockerbar menu items are only used to open other menu. Not to open a windows by itself. I opened an entry to let the menu items of the Dockerbar open a window: https://pharo.fogbugz.com/f/cases/22084/Menubar-root-items-without-children-should-be-clickable I don't know when I'll have the time to implement it. > - When a DrGeo window is open maximized, it is wrongly placed at 0@0, > its size is right but misplaced > (see screenshot2) This one is weird because when I maximize a window it works fine. I need to check what happen. > > - There are ugly frame around DrGeo menu and buttons, I don't know if it > is related to menu bar morph related modification but it's unice (see > screenshot2) Same, I'll need to take a look. Do you have a screen of the previous look please? > > The build can be tested at: > https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0 > Thank you. > Thanks > > Hilaire > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [ANN] Epicea, Ombu and Hiedra packages have new "official" repository
On 05/06/2018 17:16, Martin Dias wrote: > Hello, > > The new "official" repository for Epicea*, Ombu* and Hiedra* packages > in Pharo >= 7 is just Pharo's github > (https://github.com/pharo-project/pharo/). > > This will ease to fix a bug or add a feature on those packages. At > least, will be easy to me... > > BEFORE: > 1. Developer creates PR in github.com/pharo-project/pharo/. > 2. Integrator merges PR. > 3. I merge "upstream" (smalltalkhub/Epicea) usually several of those PRs. > 4. I create a new version in ConfigurationOfEpicea (in smalltalkhub/Epicea). > 5. I create a PR in github.com/pharo-project/pharo/ to integrate the > new version in smalltalkhub. > > NOW: > Only steps 1 and 2. Yeah! > > BTW, I did deprecate: > - Smalltalkhub repo (http://smalltalkhub.com/#!/~MartinDias/Epicea) > for pharo > 6.1 (updated its readme) > - Jenkins job (https://ci.inria.fr/pharo-contribution/job/Epicea/) > > Reference to the discussion: https://github.com/pharo-project/pharo/pull/1366 > Hello Martin, Thank you for the clarification. Can we start to change things in Epicea (like renaming tests packages to follow the convention) or do you still need to sync the Pharo version? Have a nice day. > Cheers, > Martín > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Quick menubar tweak
On 05/06/2018 13:41, Pavel Krivanek wrote: > In the current menu bar in Pharo 7 I miss launcher icons. This is a > quick ad-hoc tweak how to add them: > > > > MenubarMorph reset. > > World menubar submorphs second delete. > > World menubar addMorph: (SimpleButtonMorph new > label: '|'; > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > > World menubar addMorph: (IconicButton new > target: [ Smalltalk saveSession ]; > helpText: 'Save image'; > labelGraphic: (self iconNamed: #smallSave); > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > > World menubar addMorph: (SimpleButtonMorph new > label: '|'; > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > > World menubar addMorph: (IconicButton new > target: [ IceTipRepositoriesBrowser new openWithSpec ]; > helpText: 'Iceberg'; > labelGraphic: (IceTipRepositoriesBrowser icon); > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > World menubar addMorph: (IconicButton new > target: [ Smalltalk tools openTestRunner ]; > helpText: 'Test runner'; > labelGraphic: ( self iconNamed: #testRunnerIcon); > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > > World menubar addMorph: (IconicButton new > target: [ Smalltalk tools openWorkspace ]; > helpText: 'Playground'; > labelGraphic: ( Smalltalk tools workspace taskbarIcon); > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > World menubar addMorph: (IconicButton new > target: [ Smalltalk tools browser open ]; > helpText: 'System browser'; > labelGraphic: (self iconNamed: #nautilus); > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > > World menubar addMorph: (SimpleButtonMorph new > label: '|'; > actionSelector: #value; color: Color transparent; borderWidth: 0; > yourself) after: World menubar submorphs first. > > World menubar addMorphBack: (SimpleButtonMorph new > label: '|'; > actionSelector: #value; color: Color transparent; borderWidth: 0; yourself). > > World menubar addMorphBack: (IconicButton new > target: [ self inform: 'hello world' ]; > helpText: 'custom action'; > labelGraphic: (self iconNamed: #glamorousGo); > actionSelector: #value; color: Color transparent; borderWidth: 0; yourself). > Hi, I just created a PR to ease the creation of separators: https://github.com/pharo-project/pharo/pull/1486 GIF displaying the result is visible on this issue. -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar
On 01/06/2018 15:25, Peter Uhnák wrote: > Hi, > > I really love this idea. I've already added (hacked together) something > similar for some of my projects so I am happy to see this is going into > Pharo. > >> - Make it parametrizable to allow users to build a bar with their own menu >> builder > > I would love if it was possible to somewhere (Settings?) just specify a > pragma that should be used for the construction of the menu... or > perhaps even a list of pragmas. That way the existing mechanism can be > simply reused and custom menus can be created just as easily. > I think this should be very easy to add. > I don't know if it should be in the SettingBrowser since Pharo currently comes with only one menu (if someone know how to implement a new one it will be easy for him to find the option to change the pragma of the MenuBarMorph), but the pragma should be parametrizable in any case. > I would really love to have this option also for the regular world menu, > but I didn't find a way to easily achieve that. > >> - What do we do when Pharo is not wide enough? > > Hamburger menu? I'll rephrase, we have ideas to manage all those problems but how do we implement it? Currently there is no widget to do that and sadly we don't have enough time to create them :( > >> - What to do when a window is dragged behind? > > Currently you cannot drag window above the top side (which I've learned > only now :-D ), so the constraint would just move a bit lower? Yes, but for now when can detect a drop on the menu bar only if the cursor is over the MenubarMorph. If the user drop the window by dragging the bottom, the top of the windows will be under the MenubarMorph. > > Also, is it (easily) possible to configure the position of the menu? > Both top/down, as well as RTL and LTR direction (or right-aligned LTR) > which I mentioned for the bottom menu in an earlier github discussion. > For now I don't think so. I think it would be cool to integrate this first version then everyone can try to improve it. > Peter > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar
On 01/06/2018 15:18, Alistair Grant wrote: > Hi Guille & Cyril, > > Thanks for this. Along with being able to maximise windows > completely, making the task-bar distinct at the bottom, these are > great changes. > Yes, I did not see the problem because I use backgrounds and it was visible :) > Instead of a menu bar at the top, which takes quite a bit of space, > and as mentioned may not fit on a small screen (especially if > applications add entries), how about a "Start" button in the task-bar > that pops up the menu a-la Windows? I'm not tied to the name "Start", > it could just be an earth icon, which would save space. (This is > actually how I interpreted Cyril's original suggestion) > Personally, I would like to have display strategies for the WorldMenu and the user could select the one he likes (because nobody will agree on UI). For example: - Menu bar strategy - World menu strategy - Start button strategy - Composite strategy to have multiple ones Now it is simple to do the two first, but I will probably not have the time to implement the "Start button" one. > Cheers, > Alistair > > > -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar
Hi everyone, With Guille we are trying to improve the usability of the WorldMenu. The world menu is by large un-intuitive: - Users are not used to click on a background to open a menu - For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows. We should change that world menu by a menu bar like any application. That will lower the entrance barrier to new users, at the cost of having to move the cursor to the top to look for the menu... You can find here a PR that add the WorldMenu as a top bar to Pharo and reorganize it: https://github.com/pharo-project/pharo/pull/1470 See screen in the PR. It still have room for improvements but we think it's stable enough for integration in Pharo. Missing features: - What do we do when Pharo is not wide enough? - What to do when a window is dragged behind? - Make it parametrizable to allow users to build a bar with their own menu builder - Add shortcuts to open the menu windows like (maybe) - Update it when we change the font size (this is a general Pharo problem) Feedback is welcome. Related issue: https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar Guille & Cyril -- Cyril Ferlicot https://ferlicot.fr
[Pharo-dev] New taskbar design proposal
Hi, I always had some problems with Pharo taskbar. The first one is that it is trasparent. It takes the whole width of Pharo but only the taskbar items are visible. This is bad because we have impression that we can click on the world at the bottom right of Pharo, but we cannot. Also I did not like the style. I think we can do something that looks more current. In order to ease modifications of the taskbar style I updated Pharo to add customization points to the theme for the taskbar. With the help of the community I also corrected some bugs in the pluggable button morph that made style changes hard. (The last one I found should be corrected in this PR: https://github.com/pharo-project/pharo/pull/1384) Now that it's easier to propose new designs I would like to propose a new one. It is present on this PR: https://github.com/pharo-project/pharo/pull/1443 You can see that change following this link. I added 2 GIF showing the result with the light and dark theme. I would like to have the opinion of the community before this PR is integrated/rejected. Have a nice day. -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] FileDoesNotExist vs FileDoesNotExistException
Le 21/05/2018 à 14:58, Alistair Grant a écrit : > Hi Everyone, > > Does anyone know the history behind FileDoesNotExist and > FileDoesNotExistException? > > Both classes exist in 6.1, and as far as I can tell, both are intended > to do the same thing, i.e. the class comments are: > > FileDoesNotExist; > > I am raised when an operation is attempted on a file that does not > exist. This includes cases where a file operation is attempted on a > directory. > > > > FileDoesNotExistException: > > Notify when fie does not exist > > > > This means that programs have to check for both in exceptions, or be > very sure of whether any object they are using ultimately refers to a > File or a FileReference. > > If there isn't a good reason for having both, I think we should remove > one. Since FileDoesNotExistException is loaded first in the bootstrap > process (since it is part of Files, not FileSystem), keeping it probably > makes more sense. > > Similar duplication exists for FileAlreadyExistsException and > FileExists. > > Thoughts? > Hi Alistar, See the conversation here: https://pharo.fogbugz.com/f/cases/19026/Merge-FileDoesNotExist-and-FileDoesNotExistException > > Thanks, > Alistair > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7
Le 18/05/2018 à 21:42, Sean P. DeNigris a écrit : > Tim Mackinnon wrote >> Hi what does it mean “Iceberg does not manage yet upgrade of the local >> clones” > > This is most commonly encountered when one enables shared repository > location in Iceberg. Say you already have a local clone of Zinc in the > shared root folder, but it's out of date. Then you try to load a project > which has Zinc as a dependency, but requires the current stable version. > Iceberg will just load from the outdated clone without trying to update from > the origin remote. > > This is exactly the problem! This is something I already described here: https://github.com/pharo-vcs/iceberg/issues/723 Here is what I wrote in that thread: With a project on Monticello managed via a ConfigurationOf, when you install it it will download the .mcz in the package cache and install the project with the version/baseline you asked. If you ask for development, you'll get the latest packages described in the "development" baseline. Now, with a project hosted on github and managed via a baseline, if the Iceberg Metacello integration is enabled, when I ask to load the branch "development", I'm not sure I'll get the latest version of the packages. If there is no local clone of the project it will clone the project and checkout the latest version of the branch. But, if I already have a local clone with the branch (not in sync with the remote branch), it will install the version present locally. This version might be 5 commits behind the remote branch. That's why, maybe Iceberg can check the remote branch before installing the repository and if the local branch is behind the remote branch, it can ask the user what to do. Either install the local version or pull the install. > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?
On 09/05/2018 14:32, Hilaire wrote: > well... For me the hight contrast makes it very visible, as should be a > tooltip, and helpfull to discover feature in drgeo. > > Maybe themes could use a dictionary storing all the colors for the theme. Like that each theme should only define the default set of colors and applications can easily customize the themes by updating this dictonary. -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?
On mar. 8 mai 2018 at 15:37, Sven Van Caekenberghe <s...@stfx.eu> wrote: > Yes, it was changed. > > But for me (latest 7) it is black text on yellow background which is OK. Black and Yellow for a dark theme is readable but I do not think it is ok because it is really aggressive for the eyes. :( Usually in dark themes I see light gray for backgrounds and white or black font depending on the luminescence of the font. (Depending if it's > or < to 0.5) > > However, Print It in Playground is unreadable now ... > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] [Ann] Iceberg 0.7.5
On 03/05/2018 17:16, Guillermo Polito wrote: > Time for the weekly Iceberg update. > > Iceberg 0.7.5. will be in the next Pharo build. > Thanks to all brave users, issue reporters and contributors :). > > Key improvements: > - Several improvements in metacello integration. (see #625, #664, #688 > + more tests) > - For those using CI, we think this release will also > fix https://github.com/pharo-vcs/iceberg/issues/643 > > Infrastructure improvements: > - In 0.7.4 we introduced in the build tests againt pharo 6.1 and 64 bits > * https://travis-ci.org/pharo-vcs/iceberg/builds/372408795 > - In 0.7.5 all iceberg tests run green on Pharo 6.1 32 bits > * https://travis-ci.org/pharo-vcs/iceberg/builds/374433920 > - In the next release we plan to do a pass on 64 bits > > ** Pharo 6.1 backport ** > - We plan to backport this version to Pharo 6.1 > - Cyril has been using the development version of Iceberg on Pharo 6.1 > for a couple of weeks now. > - This plus the green CI encourages us to backport to Pharo 6.1 > > Detailed ChangesLog: > > #625 Non explicit error while loading a project > #758 [Regression] Repair action clone is not setting pharo repository > #756 Iceberg dev-0.7 is broken in Pharo6.1 (Instance of > IceTipURLLabelMorph did not understand #addEmphasis:) > #749 Adding repair actions to the code subdirectory missing problem > #655 Rename extension method buildToolbarItem of CommandActivator > #755 Extracting the URL label behavior as a component that we can reuse > #468 Commiting via Iceberg does not commit package removal > #750 Add possibility to see current commit in Repositories/Package view > #754 Showing and coping the Commit ID > #753 Create branch dialog layout is broken > #664 Package wrongly shown with "uncommited changes" status > #752 Add "invalid ssh" > #747 Cloning a Git repository should change the path with the project name. > #738 Remove "pharo" Repository with "also remove from filesystem" gives > error > #746 Make tests run on pharo 6 > #735 Issue while registering a new project on Pharo 6.1 > #733 Add license file > #740 Fogbugz panel: Improve label, focus order and layout > #549 IceRestoreRepositoryModel should have a class comment > #688 Duplicated project error when loading in a fresh image > > Enjoy, > Guille in behalf of all people that contributed :) Hi, With this integration, SmalltalkCI for Pharo 7 is green again. https://travis-ci.org/TelescopeSt/Telescope/jobs/373994423 Thank you -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] Calypso zero class refs for TComparable
On dim. 22 avr. 2018 at 03:54, Ben Coman <b...@openinworld.com> wrote: > I expected TComparable to be used somewhere in the Image? > > So I was surprised that with Calypso, > right-clicking on TComparable and choosing "Class refs" > brought up zero results. > Hi, In Nautilus the Traits are not "referenced", they are used. So you have "Find usage" instead of "Find reference". Maybe this option is missing on Calypso? (I suppose since I still use Pharo 6.1 because all my projects are around Seaside which does not load in P7) > Is this expected behaviour? (in 70793) > > cheers -ben > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-dev] How to build current VM
On sam. 21 avr. 2018 at 16:30, phideaux <jcas...@cdix.org> wrote: > I am trying to build a Pharo VM on Linux using the opensmalltalk vm git. I > just want to make sure I can reproduce the current system before > tinkering. > > I cloned the git and built the linux64x64/pharocog threaded vm (using > ./msm). The build runs fine but the vm produced when started with a current > (6.1) image says (in debug log) "vm too old for image" I have verified that > the vm level of the source in the git is the same as the latest vm > downloadable from files.pharo..org (VMMaker.oscog-eem.2361). What > additional > parameters do I need to produce a vm that matches the current latest/stable > that is 6.0/61 compatible? > Hello, Your VM is missing some metadatas. To get them execute ./scripts/updateSCCSVersions Then recompile the VM. Note that your compiled VM will still work. > Thanks in advance. > Jay+ > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- Cyril Ferlicot https://ferlicot.fr
