- Pharo-dev - lists.pharo.org

About printing without having ""
by stepharong Jan. 29, 2017

Jan. 29, 2017

Hi this is nearly more than a year that I ask if we can have a way to NOT have "" when we print a result in the tool. What is the status? This %#$&^$&*(&)**&^$%#$&%*^&( popup BREAKS the flow when writing tests. I'm FED UP to have to remove the " at the beginning and end of my expression result. We got an long discussion and now how it is handled? I have the impression that the strategy here is to make sure that people believe that they are heard but do not care. Stef -- Using Opera's mail client: http://www.opera.com/mail/

8 12

AlreadyInPharo5
by Ben Coman Jan. 29, 2017

Jan. 29, 2017

Hi Pavel, Just curious about the AlreadyInPharo5 tag being added to Issues you are sorting. For issue 14800 "AthensCanvas clipRect oddity" for example I would guess its not in Pharo 5. https://pharo.fogbugz.com/f/cases/14800 cheers -ben

3 5

pharo by example 50
by Ben Coman Jan. 28, 2017

Jan. 28, 2017

Some feedback on the download page... http://files.pharo.org/books/updated-pharo-by-example/ The four uses of use of "50" there feels out of place, since I can't help reading it as "fifty" rather than the (I presume) intended "five-zero". Perhaps insert a dot, or drop the zero. cheers -ben

2 1

Slice dependent package log message
by Ben Coman Jan. 28, 2017

Jan. 28, 2017

This is a simple by slightly invasive idea I'd like to run past the community. Sometimes when I look at packages in Pharo/main and PharoInbox/main repositories, I wonder which Issues particular package versions belongs to. So I'd like to add an automatic reference to their log message back to the Slice. I think the following could be a nice way to do it... MCWorkingCopy>>newVersionWithName: nameString message: messageString in: aRepository | info deps depsMsgString | info := ancestry infoWithName: nameString message: messageString. ancestry := MCWorkingAncestry new addAncestor: info. self modified: true; modified: false. "*" depsMsgString := messageString, String cr, String cr, 'Required by ', nameString. "*" deps := self collectDependenciesWithMessage: depsMsgString in: aRepository. (self repositoryGroup includes: aRepository) ifFalse: [ self repositoryGroup addRepository: aRepository ]. ^ MCVersion package: package info: info snapshot: package snapshot dependencies: deps Your thoughts? Changed lines marked "*". cheers -ben

1 0

MetacelloLoaderPolicy
by Ben Coman Jan. 28, 2017

Jan. 28, 2017

Hi Dale, Just tracing through a Metacello load and I see MetacelloLoaderPolicy. This has no comment and its superclass is Object so its not clear what other loader policies there might be. Is there just that one? cheers -ben

1 0

MetacelloBaseConfiguration deprecation
by Ben Coman Jan. 28, 2017

Jan. 28, 2017

In ConfigurationOfDependencyAnalyser class >> DevelopmentSupport I read... "See the methods in the 'development support' category on the class-side of MetacelloBaseConfiguration. Decide what development support methods you would like to use and copy them the the class-side of your configuration." <apiDocumentation> but MetacelloBaseConfiguration is empty and in package Metacello-Core-Deprecated. So what is the replacement? cheers -ben

1 0

Debugger layout again
by Yuriy Tymchuk Jan. 27, 2017

Jan. 27, 2017

Hi again, there is still no way to change the debugger layout to have it the same way as Mooseâ¦ Why did we change layout in Pharo in the first place? It was so nice: you had the stack with the whole highlighting on the side, so you could see more. Why do we have to make things unusable in Pharo? Uko P.S. ok, ok, I guess I will just move to Moose.

3 4

[bloc] addressing the moz2d issue
by Tudor Girba Jan. 27, 2017

Jan. 27, 2017

Hi, Thank you for the intensive set of issues you raised during the Bloc presentation. I think it is worthwhile addressing them more thoroughly, so let me start with the issue that seemed to have caused the most worries: Sparta & Moz2D. Please keep in mind that while I am involved to some extent in Bloc, the real credits for the current state go to Glenn and Alex. Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and using it puts us on par with the rendering speed of a web browser, which is a significant added value over what we have now. However, as it was noted, it does come with a cost due to the fact that it is not available as standalone with only the features we are interested in. The vector graphics part is actually buildable out of the box. However, the text support needs to be extracted out of Moz2D, and this is where the patching scripts are used. The patches are there only for compilation purposes and not for features and they are applied automatically. You can see it here: https://github.com/syrel/Moz2D Alex updated recently the Moz2D version and it worked without problems. Of course, future changes in Moz2D might imply changes in this script as well, and this implies that we will need to maintain that script. And we could imagine applying these patches on the trunk of Moz2D to see if they work, and we can also imagine engaging with the Moz2D owners to see if we can find a middle ground. Now, letâs put this into perspective. We are currently using Athens and the Cairo backend. While Cairo is provided as a standalone library it has not seen significant advances since Mozzila shifted its focus towards Moz2D. So, sticking with it might not be an ideal strategy either. Furthermore, just like Athens, Sparta is an abstraction that allows us to switch the underlying backend should we need to. Until now we did not find a cross-platform backend that is as advanced and complete as Moz2D, but there is no reason to think that none other will appear in the future. Skia is an alternative but it is only a vector graphic engine without text support, so using it would imply to have another library for the text support. Sparta also comes with a reasonable set of tests that is aimed at testing the basic Moz2D functionality to make sure that the assumptions on top of which Sparta is built are correct. All in all, I think that the current situation is not ideal, but there is already enough engineering in place to actually make it work. And I definitely think that the potential it opens is rather significant. And, if more people look at the scripts, we might find even better and cheaper ways to express it. Cheers, Doru -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

10 23

memoized vs once
by Eliot Miranda Jan. 27, 2017

Jan. 27, 2017

Hi Ben, via FaceBook via twitter I hear you've coined BlockClosure>>#memoized. Allow me to beg you to rename it to BlockClosure>>#once. There's a preexisting implementation of this in VisualWorks by Travis Griggs called once. I hope you agree that it's good to eliminate gratuitous incompatibilities between dialects and that "once" is an elegant name. _,,,^..^,,,_ best, Eliot

14 42

Immutability support
by Norbert Hartl Jan. 27, 2017

Jan. 27, 2017

Does anyone know the state of immutability support in vm and image? The latest vm downloadable is compiled with IMMUTABILITY=1 (Esteban said that). When I open a pharo6 image with this VM and do: ASUser new setIsReadOnlyObject: true; name: 'foo' with ASUser>>#name: arg1 name := arg1 I don't get an exception. Is there something missing or am I not understanding? Norbert

9 47