- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] Sharing/Versioning Data

by Eliot Miranda

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

Athens and TextMorphs

by Nicolai Hess

Working with Text and Athens only works for FreeType fonts and with Athens primitive drawString: method. Morphs with Text can not be used on an Athens. (No TextMorph rendering and no font emphasis on String or LabelMorph). But there is a AthensText package with some classes for text morph/renderer/scanner/paragraph. These are only used in AthensTextRenderTest and AthensTextMorph both don't work and AthensTextMorph should not be used (?) Classcomment: "this class is subject of changes/removal. do not use it." Where do we go from here? What is supposed to work and is it worth while to fix the missing/wrong implementations? nicolai

July 1, 2014

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

by Nicolai Hess

2014-07-01 3:16 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > > On 30 June 2014 21:36, Nicolai Hess <nicolaihess(a)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? > > >> >> >> >> 2014-06-21 1:20 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> >> : >> >> Gi Igor, >>> >>> For DrGeo it is not a workable option to have different fonts in Morphic >>> widget and Athens canvas (I explained earlier why). >>> However I found the scaling trick of draw text to work reasonably well. >>> Not full perfect as from time to time I can see some artifact. >>> >>> Thanks >>> >>> Hilaire >>> >>> >>> >>> >>> Le 20/06/2014 15:32, Igor Stasenko a Ã©crit : >>> > Sure, you can do: make sure you don't render text with same font in >>> > Morphic UI and Athens, so they don't interfere with each other. >>> > There's no easy way to get rid of interference, because it would >>> require >>> > changing Freetype package and its plugin in order to establish a single >>> > font management point and funnel all requests to freetype library >>> > through it. >>> > >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> iStoa - https://launchpad.net/istoa >>> >>> >>> >> > > > -- > Best regards, > Igor Stasenko. >

July 1, 2014

New Cog VMs available...

by Eliot Miranda

at http://www.mirandabanda.org/files/Cog/VM/VM.r3024/. I had *forgotten* to implement following forwarders on primitive failure in machine code primitives, hence Cog Spur was badly broken. It's now a little bit better, but I still need to implement this for named primitives. Real soon now I hope... CogVM source as per VMMaker.oscog-eem.791/r3024 Implement following forwarders on primitive failure in machine code interpreter primitives (still have to implement this in sideways calls of named primitives). Allow the JIT to not compile primitiveDoNamedPrimitiveWithArgs to avoid any potential complications. Rewrite all the semaphore installing primitives to fail if the semaphore arg is neither a semaphore or nil instead of assuming if its not a semaphore it must be nil, so as to fail and retry when semaphores are forwarded (as they are when Semaphore is redefined). Implement isSemaphoreOop:/Obj: in the object memories to abstract away the code. Base Spur's on the class index of splObj: ClassSemaphore, avoiding the table lookup to derive the class. Make checkForEventsMayContextSwitch: treat all its semaphores consistently. Have spur's fetchClassOfNonImm: answer nilObj for forwarders to avoid assert fails. On Spur add read barriers to primitiveSuspend and synchronousSignal:'s myList access, because the process list manipulation routines do no checking. Add assert checks for forwarders in the process list manipulation routines. Fix slip in StackInterpreter>>actuallyFollowNecessaryForwardingInMethod:literalCount: that corrupts the methodClassAssociation. Abstract out the call machinery from compileTrampolineFor:numArgs:arg:arg:arg:- arg:saveRegs:pushLinkReg:resultReg: so it can be used by maybeCompileRetry:onPrimitiveFail: in implementing following forwarders on primitive failure in machine code, and the Open PIC miss call. Have bytecodePCFor:cogMethod:startBcpc: map any pc before the stackCheckOffset to the initialPC, which applies to primitives in progress. Fix assert fails in updateStateOfSpouseContextForFrame:WithSP: and elsewhere with forwarders. LargeIntegers Plugin: Fix a latent signed shift bug in cDigitSub:len:with:len:into: caused by VMMaker.oscog-eem.785's eliminating the divide-via-shift optimization. These changes allow Cog Spur to redefine Process and/or Semaphore and not hang. -- best, Eliot

July 1, 2014

Re: [Pharo-dev] functions keys

by Pablo R. Digonzelli

The keyfunctions events does not work with the last vm Esteban give me. Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Pablo R. Digonzelli" <pdigonzelli(a)gmail.com> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Martes, 1 de Julio 2014 11:14:44 Asunto: Re: [Pharo-dev] functions keys Again like numeric pad it is a linux/pharo issue. In windows function key generates events and i can control this. Someone knows something about these linux issues ? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Pablo R. Digonzelli" <pdigonzelli(a)gmail.com> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Martes, 1 de Julio 2014 11:02:23 Asunto: Re: [Pharo-dev] functions keys Nicolai. I recheck handleEvent: , handleFocusEvent: , handleKeyUp:, handleKeyDown: and Functionkeys does not generate event at all. Other keys does. This for Linux. I will try on windows today or tomorrow. Thanks Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Pablo R. Digonzelli" <pdigonzelli(a)gmail.com> Para: nicolaihess(a)web.de, "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Martes, 1 de Julio 2014 10:45:58 Asunto: Re: [Pharo-dev] functions keys ok, sure i am wrong. I will try your suggestion nicolai . Thanks. Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Nicolai Hess" <nicolaihess(a)web.de> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Martes, 1 de Julio 2014 4:21:12 Asunto: Re: [Pharo-dev] functions keys Function keys do generate events, but no keystroke event, just keydown and keyup. you can implement handleKeyDown: or handleKeyUp: on a Morph, and it will be called on Functionkeys as well. 2014-07-01 1:55 GMT+02:00 Pablo R. Digonzelli < pdigonzelli(a)gmail.com > : Guille , functions key does not generate event at all. I think it is a problem for some applications. Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "Guillermo Polito" < guillermopolito(a)gmail.com > Para: "Pharo Development List" < pharo-dev(a)lists.pharo.org > CC: "Any question about pharo is welcome" < pharo-users(a)lists.pharo.org > Enviados: Lunes, 30 de Junio 2014 19:26:23 Asunto: Re: [Pharo-dev] functions keys To handle function keys you should handle the keyup or keydown event. Then, the KeyboardEvent has a #key method to get the pressed key. Take a look at the Key class side methods to access well known keys. Guille On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli < pdigonzelli(a)gmail.com > wrote: <blockquote> After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 </blockquote>

July 1, 2014