July 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Seeking help

by Damien Cassou

On Wed, Jul 2, 2014 at 10:18 AM, Janko Korelc <dazajn.korelc(a)gmail.com> wrote: > Could you please tell me what is going on? which operating system are you using? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 2, 2014

Seeking help

by Janko Korelc

Several days ago I was immersed in Pharo3.0 as this time things worked well. So, did include many packaeges in image up to Eye-watcer, than started to look what a repository is all about - so, was given offer to have some subdomain with my name and probably uploaded everything. Next time when I started my image from disk there was small progress bar - clearly something was updating itself or something and Eye-Watcher was in debuger window not understanding some message. Clearly had installed something unfinished or wrongly initialized. So, i deleted entire Pharo directory, and downloaded pharo, and same thing happend. Pretty nasty Huh, I am sorry if i ruined something on repository I am afraid of. Could you please tell me what is going on? Or in case i ruined repository how long does it take to fix it, please help! Thank You!

July 2, 2014

Re: [Pharo-dev] [Pharo-users] PillarHub

by Tudor Girba

+1 Doru On Wed, Jul 2, 2014 at 10:00 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Wow, amazing - great work ! > > On 02 Jul 2014, at 09:28, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > Hi everyone. > > > > Iâm so excited that I cannot keep silent. Guys from Pharocloud have > implemented online editor (and storage) for Pillar documents. This is > really amazing, and you can check it out here: > http://pillarhub.pharocloud.com/hub/pillarhub/about. > > > > They have a really nice plans, and now we can write pillar docs with > live compilation and share them online. > > > > Cheers! > > Uko > > > -- www.tudorgirba.com "Every thing has its own flow"

July 2, 2014

Re: [Pharo-dev] Athens and StrikeFont ( again )

by Henrik Sperre Johansen

On 01.07.2014 22:05, Nicolai Hess wrote: > > 2014-07-01 3:16 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>>: > > > > > On 30 June 2014 21:36, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > The real question was: > Why can't we draw a text with StrikeFont and with Athens. > > Igor, can't we use AthensCairoText (cairo toy text api) for > non-truetype fonts? > > > Because strike fonts are stored in special format which you cannot > render directly by cairo library. Because strike fonts are not > scalable. Because it will be horribly slow. Choose one. > > > > > I choose the first one, horrible slow or not scaleable is better than > a drawing error :) > > If someday all rendering is done through Athens, how do we solve this > problem with the StrikeFont? You would have to implement a special rendering path for StrikeFonts utilizing essentially the same method used for rendering bitmaps. In theory, if cairo bitmap perf is about the same as traditional bitmap perf, that'd be about as slow as FT-rendering is in non-cairo images, if there's no scaling involved. Scaled, it would probably look horrible, take a screenshot of this mail, zoom to 400% in Paint or something, that's what to expect. (Though, one *could* do some tricks translating point size /scale factor to another font with point size closer to the final result (if one exists) and get slightly less horrible results) Cheers, Henry

July 2, 2014

Re: [Pharo-dev] [Pharo-users] PillarHub

by Sven Van Caekenberghe

Wow, amazing - great work ! On 02 Jul 2014, at 09:28, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone. > > Iâm so excited that I cannot keep silent. Guys from Pharocloud have implemented online editor (and storage) for Pillar documents. This is really amazing, and you can check it out here: http://pillarhub.pharocloud.com/hub/pillarhub/about. > > They have a really nice plans, and now we can write pillar docs with live compilation and share them online. > > Cheers! > Uko

July 2, 2014

[pharo-project/pharo-core] 34668d: 40056

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 34668d4ef2bbf03e858bbb3f5021d26a83622d2e https://github.com/pharo-project/pharo-core/commit/34668d4ef2bbf03e858bbb3f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-02 (Wed, 02 Jul 2014) Changed paths: A AST-Interpreter-Core.package/extension/Slot/instance/accept_assign_inNode_.st A AST-Interpreter-Core.package/extension/Slot/instance/readWith_inNode_.st A Deprecated40.package/extension/CompiledMethod/instance/messagesDo_.st A Deprecated40.package/extension/TClass/instance/classPoolFrom_.st A Deprecated40.package/extension/TClass/instance/ensureClassPool.st R Kernel.package/CompiledMethod.class/instance/scanning/messagesDo_.st M Refactoring-Critics.package/RBAddRemoveDependentsRule.class/instance/running/checkClass_.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/possible bugs/addRemoveDependents.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script56.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40056.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/InstanceVariableSlot.class/instance/accessing/index.st A Slot.package/InstanceVariableSlot.class/instance/accessing/index_.st A Slot.package/InstanceVariableSlot.class/instance/comparing/=.st A Slot.package/InstanceVariableSlot.class/instance/comparing/hash.st A Slot.package/InstanceVariableSlot.class/instance/meta-object-protocol/read_.st A Slot.package/InstanceVariableSlot.class/instance/meta-object-protocol/write_to_.st M Slot.package/InstanceVariableSlot.class/instance/testing/isSpecial.st R Slot.package/Slot.class/instance/accessing/index.st R Slot.package/Slot.class/instance/accessing/index_.st A Slot.package/Slot.class/instance/accessing/name.st A Slot.package/Slot.class/instance/code generation/emitStore_.st A Slot.package/Slot.class/instance/code generation/emitValue_.st M Slot.package/Slot.class/instance/comparing/=.st M Slot.package/Slot.class/instance/comparing/hash.st R Slot.package/Slot.class/instance/emitting/emitStore_.st R Slot.package/Slot.class/instance/emitting/emitValue_.st M Slot.package/Slot.class/instance/meta-object-protocol/read_.st M Slot.package/Slot.class/instance/meta-object-protocol/write_to_.st R Slot.package/Slot.class/instance/private/internalRead_.st R Slot.package/Slot.class/instance/private/internalWrite_to_.st R Slot.package/Slot.class/instance/testing/name.st R Traits.package/TClass.class/instance/accessing/classPoolFrom_.st R Traits.package/TClass.class/instance/class variables/ensureClassPool.st Log Message: ----------- 40056 13445 CompiledMethod>>#messagesDo: has just two users... should be deprecated https://pharo.fogbugz.com/f/cases/13445 13444 #ensureClassPool and classPoolFrom: can be deprecated https://pharo.fogbugz.com/f/cases/13444 13446 Only InstanceVariableSlots have an #index https://pharo.fogbugz.com/f/cases/13446 http://files.pharo.org/image/40/40056.zip

July 2, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40056 Home: https://github.com/pharo-project/pharo-core

July 2, 2014

PillarHub

by Yuriy Tymchuk

Hi everyone. Iâm so excited that I cannot keep silent. Guys from Pharocloud have implemented online editor (and storage) for Pillar documents. This is really amazing, and you can check it out here: http://pillarhub.pharocloud.com/hub/pillarhub/about. They have a really nice plans, and now we can write pillar docs with live compilation and share them online. Cheers! Uko

July 2, 2014

Re: [Pharo-dev] Sharing/Versioning Data

by phil＠highoctane.be

Ah, interesting. I was looking at the theme icons yesterday and importing/exporting those would benefit from this view on resources. Also, there is the Seaside WAFileLibrary which provides some support on that front, allowing one to do a #deployFiles and get them out and also there is the support for getting them in. There is no Fuel file there. For Fuel, the main pain point is when there is an upgrade of Fuel (somewhat unexpected to the user) that renders the existing files unreadable. I had that on a StartUp and it made things weird... Not sure we want to use Fuel then. Phil On Wed, Jul 2, 2014 at 2:44 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Guillermo, > > > On Sat, Jun 28, 2014 at 11:07 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> With Martin we started on friday to sketch a kind of resource manager >> with an internal file system. Our idea is to plug a resource manager to >> each package and then serialize a fuel file of it inside the mc package. >> > > I like the idea of a file system, but don't like the idea of an internal > file system. The issue here is that I will probably want to use external > tools to create the external data, and will want to export the external > data from Monticello to an external file system when I come to deploy > (that's the point right?). So the issue is how to provide a nice interface > to determining which external files are part of a package and in including > them in the externalization of a Monticello package (e.g. the zip format of > an mcz would seem to be adequate). > > 2Â¢ > > >> But we just started it... >> > > Good luck! The one glaring hole in all the Smalltalk versioning systems > I've seen so far is the lack of support for external data. I hope you > succeed!! > > >> On Sun, Jun 29, 2014 at 5:22 AM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> >>> How do we do this now with MC? Are there options other than "encode in >>> string >>> returned by method" like I've seen done for image data? >>> >>> My use case is that I have a very static domain, and so doesn't require >>> user >>> changes. I think the easiest way to distribute it would be to edit the >>> data >>> on a dev image, and then somehow save the data in a way that can be >>> committed with MC so that loading via MetaC config loads the latest >>> version >>> of the data. What would be the best way to do that? >>> >>> Thanks. >>> >>> p.s. on a related note, I'm also interested in distributing static files >>> with the code e.g. maybe a PDF readme >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Sharing-Versioning-Data-tp4765528.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> > > > -- > best, > Eliot >

July 2, 2014

Re: [Pharo-dev] Versioner

by Norbert Hartl

> Am 30.06.2014 um 20:50 schrieb Stephan Eggermont <stephan(a)stack.nl>: > > Kilon wrote: >> I disagreed with this Stephan >> >> "That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my >fears are unfounded." >> >> this what I was replying to. > > Ok. The concrete problem we ran into with the current version of Versioner is that it > wants to resolve dependencies to exact versions. For configurations depending > on Seaside, Magritte or Grease, this is normally unwanted. They should depend on > the symbolic release versions. With the high number of changes in Pharo, exact > versions have a short lifetime. I disagree here. Using symbolic versions in a release just seems to be easier to use while being wrong. I'm talking about a "release" here. A release is only useful if you have exact versions. Everything else is asking for trouble and not reliable. That you can read in the mail archives. Nevertheless if you want a workflow where everything is updated in an uncontrolled way so be it. What you are saying is that metacello is lacking support for specifying if baseline symbolic versions should be resolved or not, right? I do not really see how versionner can influence this. Even if versionner would try to solve this in a custom way the configuration of that would have to be put in the metacello config as well. But where? Or did I miss the point? Norbert > > Dale wrote: >> In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) >> it is much easier to construct custom "tools" to support variations in workflow >> ... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... > > In order to work together effectively in open source projects it is important that > contributors know what workflow is used in a project. That is easier when the > number of different workflows is limited. Because projects depend on other projects > the number of combinations of workflow is very large. Scriptable tools can easily > support these resulting combinations. Building a GUI tool that is both very flexible > and very easy to use seems to be less easy. > > Stephan

July 2, 2014