October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Integer>>#putOn:

by Sven Van Caekenberghe

> On 12 Oct 2015, at 14:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I just spotted this: > > > Integer>>#putOn: aStream > > (aStream isBinary ifTrue: [ self asByteArray ] ifFalse: [ self asString]) putOn: aStream IMO, this is not good, implicit (and inefficient) conversions are being done. Why ? What is the exact contract of #putOn: anyway ? If the result should really depend on the argument, double dispatch might be better. > It does not look so bad at the begining, butâ¦ if I do: > > ByteArray streamContents: [ :s | 42 putOn: s ] > > I got an infinite loop. > > I know, it does not look as a very typical case, butâ¦ if Iâm writing to a Socket and I want to use > > mySocket << 255 âIACâ, thatâs exactly what will happen :( > > If I redefine it as: > > Integer>>#putOn: aStream > aStream isBinary ifFalse: [ > self asString putOn: aStream. > ^ self ]. > self asByteArray do: [ :each | aStream nextPut: each ] > > then is okâ¦ > > Would that be a good change? Yeah that looks about right, still weird, but no weirder than before ;-) > Esteban

Oct. 12, 2015

Integer>>#putOn:

by Esteban Lorenzano

Hi, I just spotted this: Integer>>#putOn: aStream (aStream isBinary ifTrue: [ self asByteArray ] ifFalse: [ self asString]) putOn: aStream It does not look so bad at the begining, butâ¦ if I do: ByteArray streamContents: [ :s | 42 putOn: s ] I got an infinite loop. I know, it does not look as a very typical case, butâ¦ if Iâm writing to a Socket and I want to use mySocket << 255 âIACâ, thatâs exactly what will happen :( If I redefine it as: Integer>>#putOn: aStream aStream isBinary ifFalse: [ self asString putOn: aStream. ^ self ]. self asByteArray do: [ :each | aStream nextPut: each ] then is okâ¦ Would that be a good change? Esteban

Oct. 12, 2015

Re: [Pharo-dev] hello

by Max Leske

> On 12 Oct 2015, at 13:53, SebastiÃ¡n Krynski <skrynski(a)gmail.com> wrote: > > Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. Hi SebastiÃ¡n, welcome! > Just writing to let you know that I'm starting to work on adding an atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. The operator will be used this way: > > a :=: b > > meaning 'swap variable a with variable b'. > In order to do this I will be modifying the VM and the Compiler . Sound cool! But isnât that the same as a become: b ? I even think that tmp := a. a := b. b := tmp is equivalent, since the VM only interrupts message sends, and in this case only byte code would be generated? Thatâs not my area of expertise, so please correct me. Cheers, Max > > I'm working under the direction of INRIA and Gabriela ArÃ©valo. >

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Thierry Goubier

2015-10-12 11:20 GMT+02:00 Christophe Demarey <Christophe.Demarey(a)inria.fr>: > > Well, the point is not to replace metacello but to go towards a per > package metadata description allowing some flexibility with the > introduction of virtual packages. > This will allow, in a first time, to set up a package repository and more > important, a web site on top of it. In a second time, I also want to enable > more flexibility in expressing dependencies constraints (eg. > 2.0, 3.*, > etc.). To achieve that, you need a very performant dependency solver and I > would like to reuse linux ones (it has be done for ocaml by example) > through CUDF (check http://mancoosi.org/) > > For now, I implemented a simple solver for static dependency constraints > (=1.2). I checked Metacello implementation and it looked to me that > approaches are a bit too far to be able to reuse the whole code. For sure, > it is not as robust as Metacello is, because you enhanced it for years. > What I want now, is to experiment (let's name it) Cargo Package Manager to > see if it fits the needs. Pharo bootstrap is the first use case. > > > What I would like, is that, at the end, the dependency solver get out of > Pharo and that we use already existing linux ones. What will stay into > Pharo are packages metadata and the way to load a list of packages. This is something I don't understand: why this focus on making this out of Pharo? What CUDF shows is that, overall, a package dependency problem can be expressed as a SAT problem which is then solvable by the appropriate solver... For example, in my ubuntu, I see that I have three (!) CUDF dependency solvers (mccf, packup, aspdcup), where mccf can use the following underlying solvers: lpsolve, cbc, Cplex, Gurobi, Glpk, SCIP or WBO (!). More interesting is packup, which rely on minisat+. Minisat, with a short search, shows up as 600 lignes of C++ (https://github.com/niklasso/minisat or http://minisat.se/) Why not porting Minisat in Pharo then? You would simplify your building your dependency issues (no need to link Pharo to yet another external tool which only works on Mac OS X / Linux :( )... And that would make such a solver available for other uses. (I think Metacello could switch to using Minisat if a Smalltalk port was available... ) In the mean-time, the number of available CUDF tools in Linux shows probably nice integration issues with dependency loading depending, on some cases, on the solver selected... cool :( Thierry

Oct. 12, 2015

hello

by SebastiÃ¡n Krynski

Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. Just writing to let you know that I'm starting to work on adding an atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. The operator will be used this way: a :=: b meaning 'swap variable a with variable b'. In order to do this I will be modifying the VM and the Compiler . I'm working under the direction of INRIA and Gabriela ArÃ©valo.

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Stephan Eggermont

On 12-10-15 10:42, Christophe Demarey wrote: > When you develop, you have a working copy of a package meta-data, including dependencies. Actually, there are current dependencies of the package. You could avoid to refer to specific versions and just point to the package name as your working image should already have packages loaded. (kind of configurationOf baseline) > When you release a version (strong act), then you "freeze" the current working version of the package meta-data and you publish it somewhere (a package repository) so that it becomes available to others. This metadata is not source cod, is easily accessible by tools and it becomes easy to build a web site on top of this to search / promote packages. What does releasing mean here? Could you frame it in terms of the 5D paper and the problems they describe? Stephna

Oct. 12, 2015

Another pass on catalog web-site (Styling)

by Esteban Lorenzano

Hi, I made another pass on catalog web-site. This time I just enhanced a bit the stylingâ¦ still a lot to do but is looking better and better: http://catalog.pharo.org (you might need a force refresh) But in fact, this announce is just an excuse to remember you to enhance your configurations with catalog information as described here: http://catalog.pharo.org/catalog/note-for-developers Also, if your configuration is proved to work on Pharo 3, 4 or 5, please copy your configuration into that repository, to avoid it to appear under âUnstableâ tag. The Catalog is just as good as the information it provides: there is A LOT of very good packages no one will ever notice (like Aconcagua, for example), that does not provide *any* information and therefore they will never be used :( PLEASE PLEASE PLEASE UPDATE YOUR CONFIGURATIONS! cheers, Esteban

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 11 oct. 2015 Ã 22:32, Dale Henrichs a Ã©crit : > When you talk about "virtual packages", I would say that a BaselineOf is pretty much a "virtual package" already. I don't think BaselineOf could be seen as a virtual package. In package A, you tell that A depends on V. In package B, you simply tell that B provides V. Many other packages could also provide V. Then, it is the solver's job to take the most relevant package providing V. > When it comes to cross-platform support there are several factors that were built into Metacello from the very beginning: > > - it should be possible to USE a package on a different platform than it was > originally written for without modifying the package itself +1 TBH, it is not yet implement in Cargo because I have a dilemnia: once you release a version, you should not edit it anymore. On another hand, you would like to say that this package released and validated on Pharo 4 is also valid for Pharo5. A good compromise would be to be able to edit only some metadata of a released package. > - it should be possible to SUBSTITUTE a platform-specific package with > another platform-specific package without modifying either of the packages with virtual packages, it becomes easy > - it should be possible to CHANGE the package dependencies based on > platform-dependent requirements without modifying any of the packages > > The key here is that if one needs to change a package to use it on a different platform then you lose the ability to share source code. > > The BaselineOf satisfies these requirements, because the "project meta data" is separate from the package/source code and the BaselineOf itself is cross-platform. > > If you haven't thought about these issues from the very beginning, then it may not be easy to shoe-horn support in after the fact ... With our approach, metadata lies in the package for the current version and it is on the package repository when the version is released. Platform-specific packages could have their own dependencies. What will be possible is to create a new package (not a source code package but a package that is used by a package manager, i.e. metadata) to support a new platform and reusing existing code (by pointing to the package source code). Do you have an example to provide to me? > With all of that said, I really do love the idea of not having to support Metacello anymore:) So I would like to see you succeed with your effort! It will take time ... I would really like to get feedbacks on Cargo because the knowledge you got with Metacello is invaluable. >>> Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) >> I do not know where christophe save his code but it is be public. > I may not have time to read a paper ... but I would have time to read code:) http://smalltalkhub.com/#!/~demarey/CargoPackageManager Regards, Christophe

Oct. 12, 2015

Re: [Pharo-dev] FilePlugin primitiveFail on Win7 slave

by Max Leske

> On 12 Oct 2015, at 11:25, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi Max, > > Have you tried to reproduce this problem in other Win7 computer than the slave? I can try in a laptop I have at home. Yes, I did. In my VirtualBox image all the tests are green. > > Martin > > On Fri, Oct 9, 2015 at 5:53 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > Hey guys, is there a known problem with the FilePlugin on the Win7 slave? Whenever I try to delete a file I get a primitiveFailed. > > As you can see in the trace below, Iâm actually even checking for FileNotFound, which means that the file exists but the VM canât perform the operation for some reason. > > > Cheers, > Max > > > > FilePluginPrims(Object)>>primitiveFailed: > FilePluginPrims(Object)>>primitiveFailed > FilePluginPrims>>deleteDirectory: > WindowsStore(DiskStore)>>delete: > FileSystem>>delete: > FileReference>>delete > DeleteVisitor>>visitReference: > DeleteVisitor(FileSystemVisitor)>>visitDirectory: > PostorderGuide>>visit: > Message>>sendTo: > [ self pop sendTo: self ] in PostorderGuide>>show: > PostorderGuide(FileSystemGuide)>>whileNotDoneDo: > PostorderGuide>>show: > PostorderGuide class(FileSystemGuide class)>>show:to:selecting: > DeleteVisitor>>visit: > DeleteVisitor class>>delete: > FileReference(AbstractFileReference)>>deleteAll > [ ref deleteAll ] in [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in the File plugin" ] ] in LGitTestRepository class>>tearDown > BlockClosure>>on:do: > [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in the File plugin" ] ] in LGitTestRepository class>>tearDown > FileReference(Object)>>in: > LGitTestRepository class>>tearDown > LGitBlobTest(LGitTestCase)>>tearDown >

Oct. 12, 2015

Re: [Pharo-dev] FilePlugin primitiveFail on Win7 slave

by Martin Dias

Hi Max, Have you tried to reproduce this problem in other Win7 computer than the slave? I can try in a laptop I have at home. Martin On Fri, Oct 9, 2015 at 5:53 PM, Max Leske <maxleske(a)gmail.com> wrote: > Hey guys, is there a known problem with the FilePlugin on the Win7 slave? > Whenever I try to delete a file I get a primitiveFailed. > > As you can see in the trace below, Iâm actually even checking for > FileNotFound, which means that the file exists but the VM canât perform the > operation for some reason. > > > Cheers, > Max > > > > FilePluginPrims(Object)>>primitiveFailed: > FilePluginPrims(Object)>>primitiveFailed > FilePluginPrims>>deleteDirectory: > WindowsStore(DiskStore)>>delete: > FileSystem>>delete: > FileReference>>delete > DeleteVisitor>>visitReference: > DeleteVisitor(FileSystemVisitor)>>visitDirectory: > PostorderGuide>>visit: > Message>>sendTo: > [ self pop sendTo: self ] in PostorderGuide>>show: > PostorderGuide(FileSystemGuide)>>whileNotDoneDo: > PostorderGuide>>show: > PostorderGuide class(FileSystemGuide class)>>show:to:selecting: > DeleteVisitor>>visit: > DeleteVisitor class>>delete: > FileReference(AbstractFileReference)>>deleteAll > [ ref deleteAll ] in [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in > the File plugin" ] ] in LGitTestRepository class>>tearDown > BlockClosure>>on:do: > [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in > the File plugin" ] ] in LGitTestRepository class>>tearDown > FileReference(Object)>>in: > LGitTestRepository class>>tearDown > LGitBlobTest(LGitTestCase)>>tearDown >

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 11 oct. 2015 Ã 18:42, Dale Henrichs a Ã©crit : > > > On 10/11/15 12:19 AM, stepharo wrote: >> >> >> Le 11/10/15 00:40, Dale Henrichs a Ã©crit : >>> Christophe, >>> >>> I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, >> you should read it. :) >> We wrote it for that and it is not boring nor long. > I scanned through it at the time and as I recall, I thought that the functionality described was already covered by git and BaselineOf ... but I did not read it in great detail and I did not (and still don't) have the time to compose a long-winded response:) >> >>> but I am curious how you think "package dependencies" will play with git-based projects? >>> >>> In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. >> >> I think that this is only true for packages committed within the same repo. >> Now between porjects published in different repo you have to express them. >> I do not think that we all want to publish in the same repo and clone out everything. > ... and inter-project dependencies is what a BaselineOf does .... which brings me back to the conclusion that I reached when I scanned the paper:) >>> >>> In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... >>> >>> I guess I don't know what you mean when you say: >>>> we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). >>> Perhaps a description of the problem being solved would help me understand. >> We want to be able to have a package market place where tools can grab dependencies without to load code >> and can compute the set of packages that should be loaded. >> >> When a package is released into the market: then it externalise its metadata so that a crawler can automatically build >> dependency graph and create specific distribution. > Okay. This is a problem .... but it happens to be a problem that Metacello "can solve/does solve" - so there must be something else (a deeper problem?) that I don't quite understand. > > With that said, if you are planning to replace Metacello, then I am excited:) But I will repeat that I hope that you are considering cross platform issues ... > > Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) Well, the point is not to replace metacello but to go towards a per package metadata description allowing some flexibility with the introduction of virtual packages. This will allow, in a first time, to set up a package repository and more important, a web site on top of it. In a second time, I also want to enable more flexibility in expressing dependencies constraints (eg. > 2.0, 3.*, etc.). To achieve that, you need a very performant dependency solver and I would like to reuse linux ones (it has be done for ocaml by example) through CUDF (check http://mancoosi.org/) For now, I implemented a simple solver for static dependency constraints (=1.2). I checked Metacello implementation and it looked to me that approaches are a bit too far to be able to reuse the whole code. For sure, it is not as robust as Metacello is, because you enhanced it for years. What I want now, is to experiment (let's name it) Cargo Package Manager to see if it fits the needs. Pharo bootstrap is the first use case. What I would like, is that, at the end, the dependency solver get out of Pharo and that we use already existing linux ones. What will stay into Pharo are packages metadata and the way to load a list of packages.

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Hi Dale, Le 11 oct. 2015 Ã 00:40, Dale Henrichs a Ã©crit : > Christophe, > > I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, but I am curious how you think "package dependencies" will play with git-based projects? Dependencies are not tied to a Version Control System (monticello, git or whatever). Dependencies are a package concern. With a released version, at the end, we need to fech source code from a VCS (as we do not have a shared binary format): these steps are already done by MC*Repository classes, including git. > In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. Git allows you to easily reference a set of packages working together. It works fine for packages of the same repository but you get back the problem since you deal with packages of other repositories. > In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... For the first step of the bootstrap, it will work but not for next steps where we will split the Pharo image into different projects. > I guess I don't know what you mean when you say: >> we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). > Perhaps a description of the problem being solved would help me understand. When you develop, you have a working copy of a package meta-data, including dependencies. Actually, there are current dependencies of the package. You could avoid to refer to specific versions and just point to the package name as your working image should already have packages loaded. (kind of configurationOf baseline) When you release a version (strong act), then you "freeze" the current working version of the package meta-data and you publish it somewhere (a package repository) so that it becomes available to others. This metadata is not source cod, is easily accessible by tools and it becomes easy to build a web site on top of this to search / promote packages. So, the problems I'm trying to solve there are: do not be tied to a VCS and do not need to load code to "play" with packages metadata offer a central place to easily find the package you need (for example, java has http://central.sonatype.org/, php has https://packagist.org/, etc.) do not mix preoccupations: I do not want to have metadata of all released versions + working copy of a package at the same place Christophe

Oct. 12, 2015

[pharo-project/pharo-core] b3031d: 50381

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b3031d243c04ad2bd5c673f9805499c4852e4661 https://github.com/pharo-project/pharo-core/commit/b3031d243c04ad2bd5c673f9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-12 (Mon, 12 Oct 2015) Changed paths: R Collections-Abstract.package/Collection.class/instance/accessing/atRandom.st R Collections-Abstract.package/Collection.class/instance/accessing/atRandom_.st R Collections-Abstract.package/SequenceableCollection.class/instance/accessing/atRandom_.st R Collections-Tests.package/SetTest.class/instance/some tests/testAtRandom.st R Collections-Unordered.package/Matrix.class/instance/accessing/atRandom.st R Collections-Unordered.package/Matrix.class/instance/accessing/atRandom_.st R Collections-Unordered.package/Set.class/instance/accessing/atRandom_.st R Kernel-Tests.package/RandomTest.class/README.md R Kernel-Tests.package/RandomTest.class/definition.st R Kernel-Tests.package/RandomTest.class/instance/running/setUp.st R Kernel-Tests.package/RandomTest.class/instance/tests/testNext.st M Kernel.package/Context.class/class/instance creation/basicNew_.st M Kernel.package/Context.class/instance/controlling/shortDebugStack.st M Kernel.package/Context.class/instance/printing/debugStackOn_.st M Kernel.package/Context.class/instance/printing/debugStack_on_.st M Kernel.package/Context.class/instance/printing/printOn_.st M Kernel.package/Exception.class/instance/handling/freeze.st R Kernel.package/Integer.class/instance/truncation and round off/atRandom.st R Kernel.package/Integer.class/instance/truncation and round off/atRandom_.st R Kernel.package/Random.class/README.md R Kernel.package/Random.class/class/instance creation/seed_.st R Kernel.package/Random.class/class/testing/bucketTest_.st R Kernel.package/Random.class/class/testing/theItsCompletelyBrokenTest.st R Kernel.package/Random.class/definition.st R Kernel.package/Random.class/instance/accessing/next.st R Kernel.package/Random.class/instance/accessing/nextInt_.st R Kernel.package/Random.class/instance/accessing/next_.st R Kernel.package/Random.class/instance/accessing/next_into_.st R Kernel.package/Random.class/instance/initialization/initialize.st R Kernel.package/Random.class/instance/initialization/seed_.st R Kernel.package/Random.class/instance/private/nextValue.st R Kernel.package/Random.class/instance/private/seed.st A Random.package/Random.class/README.md A Random.package/Random.class/class/instance creation/seed_.st A Random.package/Random.class/class/testing/bucketTest_.st A Random.package/Random.class/definition.st A Random.package/Random.class/instance/accessing/next.st A Random.package/Random.class/instance/accessing/nextInt_.st A Random.package/Random.class/instance/accessing/next_.st A Random.package/Random.class/instance/accessing/next_into_.st A Random.package/Random.class/instance/initialization/initialize.st A Random.package/Random.class/instance/initialization/seed_.st A Random.package/Random.class/instance/private/privateNextSeed.st A Random.package/Random.class/instance/private/privateNextValue.st A Random.package/Random.class/instance/private/seed.st A Random.package/RandomTest.class/README.md A Random.package/RandomTest.class/definition.st A Random.package/RandomTest.class/instance/running/setUp.st A Random.package/RandomTest.class/instance/tests/testIfCompletelyBroken.st A Random.package/RandomTest.class/instance/tests/testNext.st A Random.package/SharedRandom.class/README.md A Random.package/SharedRandom.class/class/accessing/globalGenerator.st A Random.package/SharedRandom.class/class/initialization/initialize.st A Random.package/SharedRandom.class/definition.st A Random.package/SharedRandom.class/instance/accessing/next.st A Random.package/SharedRandom.class/instance/accessing/nextInt_.st A Random.package/SharedRandom.class/instance/accessing/next_into_.st A Random.package/SharedRandom.class/instance/initialization/initialize.st A Random.package/extension/Collection/instance/atRandom.st A Random.package/extension/Collection/instance/atRandom_.st A Random.package/extension/Integer/instance/atRandom.st A Random.package/extension/Integer/instance/atRandom_.st A Random.package/extension/Matrix/instance/atRandom.st A Random.package/extension/Matrix/instance/atRandom_.st A Random.package/extension/SequenceableCollection/instance/atRandom_.st A Random.package/extension/Set/instance/atRandom_.st A Random.package/extension/SetTest/instance/testAtRandom.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50380.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50381.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50380.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50381.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50381 16761 Method source should not contain linefeeds in Kernel https://pharo.fogbugz.com/f/cases/16761 16577 Random should be in its own package https://pharo.fogbugz.com/f/cases/16577 http://files.pharo.org/image/50/50381.zip

Oct. 12, 2015

[pharo-project/pharo-core]

by GitHub

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

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by stepharo

> > A BaselineOf has a single baseline method and only the "pure" > dependencies amongst the packages and projects needs to be expressed > ... and these dependency specs are about "as small" as you can get ... >> Yes but we want them per package. We do not work on that since more than one year by accident. >>>> >>>> When a package is released into the market: then it externalise its >>>> metadata so that a crawler can automatically build >>>> dependency graph and create specific distribution. >>> Okay. This is a problem .... but it happens to be a problem that >>> Metacello "can solve/does solve" - so there must be something else >>> (a deeper problem?) that I don't quite understand. >> But you have to load the configuration and somehow execute it so that >> it computes the dependencies and we do not want. > Do you recall that I have been reminding folks that the specifications > for ConfigurationOf and BaselineOf will someday become an XML file? > ... I have taken great pains over the years to preserve this > "expectation" ... Remember the choice to use classes was made as a > bootstrap convenience to avoid having to create tools ... 6 years > later and there is still a dearth of tools:) > > When you "execute" the code in a ConfigurationOf or BaselineOf, a > completely separate data structure is constructed using a well-defined > API and it is this "data structure" that does the real work ... it > would be very easy to convert a BaselineOf into an XML/JSON/STON file > without losing any information, unless you've have disregarding my > warnings:) > > There is nothing in Metacello "project specifications" that _depends_ > upon executing code ... I know what I meant was use of pragmas, chaining pragma, loading all the configuration information (different baselines....). >>> With that said, if you are planning to replace Metacello, then I am >>> excited:) But I will repeat that I hope that you are considering >>> cross platform issues ... >> Yes we do. First we wanted to make it work. Then we should have kind >> of virtual packages that act as platforms or project level > When you talk about "virtual packages", I would say that a BaselineOf > is pretty much a "virtual package" already. > > When it comes to cross-platform support there are several factors that > were built into Metacello from the very beginning: > > - it should be possible to USE a package on a different platform > than it was > originally written for without modifying the package itself > - it should be possible to SUBSTITUTE a platform-specific package with > another platform-specific package without modifying either of the > packages > - it should be possible to CHANGE the package dependencies based on > platform-dependent requirements without modifying any of the > packages > > The key here is that if one needs to change a package to use it on a > different platform then you lose the ability to share source code. I see well the reason. :) The last point is the most tricky one when we have per package dependencies. But I will let christophe answers. > > The BaselineOf satisfies these requirements, because the "project meta > data" is separate from the package/source code and the BaselineOf > itself is cross-platform. > > If you haven't thought about these issues from the very beginning, > then it may not be easy to shoe-horn support in after the fact ... I will let christophe answer. > > With all of that said, I really do love the idea of not having to > support Metacello anymore:) So I would like to see you succeed with > your effort! Thanks. We will need help definitively. >>> Perhaps at this point in time, I'd like to read some code. Then I >>> can skip reading the paper and get a feel for how hard it will be to >>> port to GemStone:) >> I do not know where christophe save his code but it is be public. > I may not have time to read a paper ... but I would have time to read > code:) :) > > Dale > >

Oct. 12, 2015

Re: [Pharo-dev] MultistateLabelMorph still required

by Marcus Denker

> On 12 Oct 2015, at 01:38, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > from Web history I see that it was a Polymorph extension from Gary Chambers: > "Added MultistateLabelMorph that can adapt to interaction sates from buttons." > > http://forum.world.st/update-1-1-11293-Polymorph-Enhancements-td1680386.html > > In Pharo5.0 Latest update: #50380 one can see that it is not referenced. > Do we still need it or can we move it to deprecated? > I would say we deprecate. Marcus

Oct. 12, 2015

MultistateLabelMorph still required

by Torsten Bergmann

Hi, from Web history I see that it was a Polymorph extension from Gary Chambers: "Added MultistateLabelMorph that can adapt to interaction sates from buttons." http://forum.world.st/update-1-1-11293-Polymorph-Enhancements-td1680386.html In Pharo5.0 Latest update: #50380 one can see that it is not referenced. Do we still need it or can we move it to deprecated? Thanks T.

Oct. 11, 2015

Re: [Pharo-dev] Yet another Athens font thread

by Nicolai Hess

2015-10-09 22:43 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > No, they are needed. Because glyphs must be calculated (getGlyphs:of:) > after(!) setting font size. Otherwise there are huge gaps between > characters. > When font problem appears, some characters are of size 14 even if font > size 10. So glyphs of big characters have larger extent as it should be. In > your example you set font size and fix font, so all characters are rendered > correctly, but at wrong positions. That is a source of unnecessary gaps. > Ok, I understand. In what situation do you see huge gaps between glyphs? I only know about the problem of wrong sized glyphs. > Thete is a way to break font: > > 1) Get new pharo image > 2) Get Bloc > 3) Switch to bloc > 4) remove all morphs > 5) save and quite > 6) open image > 7) open nautilus > > Do something to fix font. Repeat 4-7. If fix is "fake" fonts will be > broken.. > On Oct 9, 2015 10:31 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: > >> >> >> 2015-10-08 18:05 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >> >>> Do you remember a hack with scaling? (scaleBy: 1.0001(a)1.0001) It makes >>> letters to have the same height, so no more huge ones with small fonts. But >>> it doesn't fix a bug when letters have wrong width so there is a space >>> between characters. The same effect can be achieved if we set font size >>> manually after setting scaled font before drawing glyphs with cairo. It >>> means that at some point we get wrong calculated glyphs. So if we "fix" >>> scaled font before glyph calculation - the problem would be gone. In the >>> patch I set scaled font, manually apply font size, retrieve "fixed" scaled >>> font and calculate glyphs based on it. >>> >>> Also after investigation I found something interesting. If we clean real >>> font of a logical font the problem gets fixed for some period of time. I >>> assume that FreeTypeFont gets broken after a while and logical font always >>> returns broken real font. Setting realFont to nil forces logical font to >>> create a new working free type font. As soon as new free type font is >>> created cairo produces scaled font and caches it. So actual problem lies >>> deep in FreeTypeFont... >>> >>> I even opened two images: one with broken fonts and one with working. >>> Then I compared in inspector two free type fonts - they are absolutely the >>> same and have identical instance variable in a whole object tree, except of >>> handler pointers to C structure which I can't inspect from pharo... >>> >>> Saving image fixes fonts because of >>> >>>> LogicalFont>>shutDown: quitting >>>> self allSubInstances do: [:i | i clearRealFont]. >>> >>> >>> Cheers, >>> Alex >>> >> >> This is great. >> >> I looked at your change. And noticed the call to >> setFontSize >> this was never called until now. Maybe this was the problem. >> >> Now, I just changed >> >> renderGlyphs: cairoGlyphs >> >> font lock. >> canvas >> setPathMatrix; >> setScaledFont: font; >> setFontSize: originalFont pixelSize. "<< new " >> canvas paint loadOnCairoCanvas: canvas. >> >> canvas showGlyphs: cairoGlyphs address size: cairoGlyphs size. >> font unlock. >> >> And it seems the font issue is gone. Maybe the other changes (set and get >> scaled font in #glyphsOf:from:to: ) >> isn't needed? (needs more tests) >> >> >> >>> On Thu, Oct 8, 2015 at 5:43 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> How did you fix it? >>>> Am 08.10.2015 17:06 schrieb "Aliaksei Syrel" <alex.syrel(a)gmail.com>: >>>> >>>>> Hi >>>>> >>>>> It looks like I fixed that weird text rendering problem... Just get >>>>> the latest Athens-Cairo. >>>>> >>>>> Cheers, >>>>> Alex >>>>> >>>>> On Mon, Aug 3, 2015 at 9:32 PM, Nicolai Hess <nicolaihess(a)web.de> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2015-06-10 12:01 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I noticed that if I force use "Source Code Pro" as standard font for >>>>>>> all elements in the image I never have problems with font rendering. In >>>>>>> case of "Source Sans Pro" font is just not usable becasue of rendering bugs >>>>>>> on mac, windows and linux(?). If "Lucida Sans Pro" is used - no bugs too. >>>>>>> >>>>>>> Because bug is reproducable on all platform - it's platform >>>>>>> independent bug. >>>>>>> Because it's reproducable only with one specific font - maybe it's >>>>>>> not an athens issue but bug in font itself and if someone could >>>>>>> change/update Source Sans Pro to a newly version or to a similar font the >>>>>>> problem will be solved? >>>>>>> >>>>>> >>>>>> Did you try to use a new font version ? >>>>>> I don't know exactly how embedded fonts are included. I tried to >>>>>> create the font with a newer version but it did not work ( or at least I >>>>>> could not see any difference). >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alex >>>>>>> >>>>>> >>>>>> >>>>> >>> >>

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/11/15 11:40 AM, stepharo wrote: > >> >>> I think that this is only true for packages committed within the >>> same repo. >>> Now between porjects published in different repo you have to express >>> them. >>> I do not think that we all want to publish in the same repo and >>> clone out everything. >> ... and inter-project dependencies is what a BaselineOf does .... >> which brings me back to the conclusion that I reached when I scanned >> the paper:) > Yes probably but you have to have a BaselineOf for every package. > Because we want to have the dependency expressed in every package and > not in > a gigantic "project" configuration of. If you are talking about ConfigurationOf, then I agree that they can be gigantic, but 99% of the junk in a configuration is completely eliminated when you use a BaselineOf ... 99% of the junk in a configuration is dedicated to plugging the gap between monticello as an SCM and built-in capabilities for git ... A BaselineOf has a single baseline method and only the "pure" dependencies amongst the packages and projects needs to be expressed ... and these dependency specs are about "as small" as you can get ... > >>> >>> When a package is released into the market: then it externalise its >>> metadata so that a crawler can automatically build >>> dependency graph and create specific distribution. >> Okay. This is a problem .... but it happens to be a problem that >> Metacello "can solve/does solve" - so there must be something else (a >> deeper problem?) that I don't quite understand. > But you have to load the configuration and somehow execute it so that > it computes the dependencies and we do not want. Do you recall that I have been reminding folks that the specifications for ConfigurationOf and BaselineOf will someday become an XML file? ... I have taken great pains over the years to preserve this "expectation" ... Remember the choice to use classes was made as a bootstrap convenience to avoid having to create tools ... 6 years later and there is still a dearth of tools:) When you "execute" the code in a ConfigurationOf or BaselineOf, a completely separate data structure is constructed using a well-defined API and it is this "data structure" that does the real work ... it would be very easy to convert a BaselineOf into an XML/JSON/STON file without losing any information, unless you've have disregarding my warnings:) There is nothing in Metacello "project specifications" that _depends_ upon executing code ... > >> With that said, if you are planning to replace Metacello, then I am >> excited:) But I will repeat that I hope that you are considering >> cross platform issues ... > Yes we do. First we wanted to make it work. Then we should have kind > of virtual packages that act as platforms or project level When you talk about "virtual packages", I would say that a BaselineOf is pretty much a "virtual package" already. When it comes to cross-platform support there are several factors that were built into Metacello from the very beginning: - it should be possible to USE a package on a different platform than it was originally written for without modifying the package itself - it should be possible to SUBSTITUTE a platform-specific package with another platform-specific package without modifying either of the packages - it should be possible to CHANGE the package dependencies based on platform-dependent requirements without modifying any of the packages The key here is that if one needs to change a package to use it on a different platform then you lose the ability to share source code. The BaselineOf satisfies these requirements, because the "project meta data" is separate from the package/source code and the BaselineOf itself is cross-platform. If you haven't thought about these issues from the very beginning, then it may not be easy to shoe-horn support in after the fact ... With all of that said, I really do love the idea of not having to support Metacello anymore:) So I would like to see you succeed with your effort! > >> Perhaps at this point in time, I'd like to read some code. Then I can >> skip reading the paper and get a feel for how hard it will be to port >> to GemStone:) > I do not know where christophe save his code but it is be public. I may not have time to read a paper ... but I would have time to read code:) Dale

Oct. 11, 2015

taskbarThumbnail leaks memory?

by Henrik Nergaard

It looks like the taskbarThumbnails might be leaking memory. When moving the mouse across the taskbar viewing the different thumbnails the memory usage increases by quite a lot (viewed in the taskmanager (Windows) ). I made an example script to illustrate the resource usage. Test scenario: 20 windows; 1 Playground, 19 Nautilus browsers (these are minimized). =============== Create Test Scenario ======================== 19 timesRepeat: [ Nautilus openOnClass: Object. World doOneCycle. ]. World doOneCycle. World submorphs select: [ :m | m isKindOf: NautilusWindow ] thenDo: [ :m | m minimize ] ===== Enumerate the mouse moving from one taskbarButton to the next ======= | delay | delay := [ :msToWait | | t | t := Time now asMilliSeconds. [ (Time now asMilliSeconds - t) < msToWait ] whileTrue: [ World doOneCycle ]. ]. 20 timesRepeat: [ World submorphs detect: [:m | m isTaskbar ] ifFound: [ :taskbar | taskbar orderedTasks collect: [ :task | task morph ] thenDo: [ :morph | | button | button := (taskbar taskButtonOf: morph). morph taskbarButtonEntered: button event: nil in: nil. delay value: 100. morph taskbarButtonLeft: button event: nil in: nil. delay value: 100 ] ]. Smalltalk garbageCollect. ]. ============================================================ Results: (Newest Win vm -> Image 50377) opening the 20 Windows RAM used is 70MB. 1 iteration: 93MB 20 iterations: 130MB \ 190 MB when garbageCollect is commented out. Should the resource usage be that high? (a taskbarThumbnail is deleted before the next one is shown...) Best regards, Henrik

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by stepharo

> >> I think that this is only true for packages committed within the same >> repo. >> Now between porjects published in different repo you have to express >> them. >> I do not think that we all want to publish in the same repo and clone >> out everything. > ... and inter-project dependencies is what a BaselineOf does .... > which brings me back to the conclusion that I reached when I scanned > the paper:) Yes probably but you have to have a BaselineOf for every package. Because we want to have the dependency expressed in every package and not in a gigantic "project" configuration of. >> >> When a package is released into the market: then it externalise its >> metadata so that a crawler can automatically build >> dependency graph and create specific distribution. > Okay. This is a problem .... but it happens to be a problem that > Metacello "can solve/does solve" - so there must be something else (a > deeper problem?) that I don't quite understand. But you have to load the configuration and somehow execute it so that it computes the dependencies and we do not want. > With that said, if you are planning to replace Metacello, then I am > excited:) But I will repeat that I hope that you are considering cross > platform issues ... Yes we do. First we wanted to make it work. Then we should have kind of virtual packages that act as platforms or project level > Perhaps at this point in time, I'd like to read some code. Then I can > skip reading the paper and get a feel for how hard it will be to port > to GemStone:) I do not know where christophe save his code but it is be public. > > Dale > >

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections. A solution for some.

by Ralph Boland

I haven't followed this thread closely so I apologize in advance if I am somewhat off topic but I think what I have to say may be of interest to some of you. I think the current method of determining a hash value for a collection is fine in the general case and if it is inadequate for your particular needs then implement your own collection class that does what you want. This was the case for one of my applications so I created classes HashArray and HashSet. Both of these classes used as their hash value the XOR of the the hash values of the collection elements (which was of course stored in an instance variable). Each time an element was added, removed, or replaced in the collection the hash value of the collection had to be recomputed (required O(1) time). Of course this approach breaks down if the collection elements can change their hash values. My solution is not ideal for the hashArray case because two hashArrays containing the same elements but in a different order would have the same hash value. But this didn't matter for my application because I used hashArrays as a set converted into an array (with values sorted) for time/space efficiency reasons. This worked really well for me, in part because the elements stored in the hashArrays and hashSets also had really good hash values. Also note that, in my application, two hashArrays or hashSets containing the same elements were considered to be equal. If anyone makes use of this idea I wouldn't mind a quick email on your experience. Ralph Boland

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/11/15 12:19 AM, stepharo wrote: > > > Le 11/10/15 00:40, Dale Henrichs a Ã©crit : >> Christophe, >> >> I still don't have a lot of time to read the paper and try to >> understand what you are trying to accomplish, > you should read it. :) > We wrote it for that and it is not boring nor long. I scanned through it at the time and as I recall, I thought that the functionality described was already covered by git and BaselineOf ... but I did not read it in great detail and I did not (and still don't) have the time to compose a long-winded response:) > >> but I am curious how you think "package dependencies" will play with >> git-based projects? >> >> In git-based repositories I don't think you have the same type of >> dependency issues that one might have with monticello repositories >> --- In a monticello repository you have a whole range of possible >> package versions to pick from, but in a git-based repository the >> range of package versions is fixed to those that are committed >> together so the packages that are meant to work together are >> committed together. > > I think that this is only true for packages committed within the same > repo. > Now between porjects published in different repo you have to express > them. > I do not think that we all want to publish in the same repo and clone > out everything. ... and inter-project dependencies is what a BaselineOf does .... which brings me back to the conclusion that I reached when I scanned the paper:) >> >> In the bootstrap scenario, you would only have one version per >> package to choose from, so the packages that are meant to work >> together are committed together .... >> >> I guess I don't know what you mean when you say: >>> we want to decouple a released version of a package from the working >>> copy of the package version description (implies the creation of a >>> package repository + a web interface on top of it to promote/search >>> packages). >> Perhaps a description of the problem being solved would help me >> understand. > We want to be able to have a package market place where tools can grab > dependencies without to load code > and can compute the set of packages that should be loaded. > > When a package is released into the market: then it externalise its > metadata so that a crawler can automatically build > dependency graph and create specific distribution. Okay. This is a problem .... but it happens to be a problem that Metacello "can solve/does solve" - so there must be something else (a deeper problem?) that I don't quite understand. With that said, if you are planning to replace Metacello, then I am excited:) But I will repeat that I hope that you are considering cross platform issues ... Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) Dale

Oct. 11, 2015

Re: [Pharo-dev] A really cool thread on fog bug

by Ben Coman

Glad to help. cheers -ben On Sun, Oct 11, 2015 at 4:58 PM, stepharo <stepharo(a)free.fr> wrote: > https://pharo.fogbugz.com/f/cases/16577/Random-should-be-in-its-own-package > > I love the spirit of this thread!!! > Thank you for this example of collaboration. > > > I wrote : > > I want to **really** thank you. > This thread is great and show the power of collaboration. > We all stronger and better. > Thanks again. >

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections

by monty

The issue: https://pharo.fogbugz.com/f/cases/16760/Dictionary-breaks-when-comparing-id… > Sent: Sunday, October 11, 2015 at 7:23 AM > From: monty <monty2(a)programmer.net> > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] hash and Collections > > Resending because the last was HTML'd: > > Never use #newFrom: with associations from another dictonary if you reuse the first after. > Â > The bug is actually deeper than you know: > dic1 := Dictionary newFrom:{'test' -> 4}. > dic2 := IdentityDictionary newFrom: {'test' copy -> 4}. > dic1 = dic2. > dic2 = dic1. > Â > Depending on the order, they are equal or inequal. > Â > The bug is caused by Dictionary>>= using a polymorphic type test #isDictionary. Squeak is unaffected: its #= uses a hardcoded class == test. The least disruptive fix I can think of is adding another type test #isIdentityDictionary in Dictionary that returns false but returns true for every identity dictionary class (like SmalllIdentityDictionary). Then only compare the associations if "self isIdentityDictionary = aDictionary isIdentityDictionary". > Â > I will open an issue. > >

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections

by monty

Resending because the last was HTML'd: Never use #newFrom: with associations from another dictonary if you reuse the first after. Â The bug is actually deeper than you know: dic1 := Dictionary newFrom:{'test' -> 4}. dic2 := IdentityDictionary newFrom: {'test' copy -> 4}. dic1 = dic2. dic2 = dic1. Â Depending on the order, they are equal or inequal. Â The bug is caused by Dictionary>>= using a polymorphic type test #isDictionary. Squeak is unaffected: its #= uses a hardcoded class == test. The least disruptive fix I can think of is adding another type test #isIdentityDictionary in Dictionary that returns false but returns true for every identity dictionary class (like SmalllIdentityDictionary). Then only compare the associations if "self isIdentityDictionary = aDictionary isIdentityDictionary". Â I will open an issue.

Oct. 11, 2015

Re: [Pharo-dev] hash and Collections

by monty

Oct. 11, 2015

Re: [Pharo-dev] [Slots] Slides from ESUG: Variables in Pharo5

by serge.stinckwich＠gmail.com

Thank you Marcus. This was not urgent matter for me ;-) I don't remember if I give the slides. Please ping me if they are missing. Sent from my iPhone > On 11 oct. 2015, at 11:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 11 Oct 2015, at 09:36, serge.stinckwich(a)gmail.com wrote: >> >> Great job Marcus ! >> I could not the SciSmalltalk talk. This was maybe not recorded ? > > Yes, I am missing SciSmalltalk and Block. But I do have some more videos > to go through (not many and they are supposed to be from tuesday afternoon). > > I am now going through the talks one by one from the startâ¦ doing all the small > stuff (converting slides to pdf, upload slideshare, check if video existsâ¦) > > Monday looks already good. > > Marcus > >

Oct. 11, 2015

Re: [Pharo-dev] [Slots] Slides from ESUG: Variables in Pharo5

by Marcus Denker

> On 11 Oct 2015, at 09:36, serge.stinckwich(a)gmail.com wrote: > > Great job Marcus ! > I could not the SciSmalltalk talk. This was maybe not recorded ? Yes, I am missing SciSmalltalk and Block. But I do have some more videos to go through (not many and they are supposed to be from tuesday afternoon). I am now going through the talks one by one from the startâ¦ doing all the small stuff (converting slides to pdf, upload slideshare, check if video existsâ¦) Monday looks already good. Marcus

Oct. 11, 2015

A really cool thread on fog bug

by stepharo

https://pharo.fogbugz.com/f/cases/16577/Random-should-be-in-its-own-package I love the spirit of this thread!!! Thank you for this example of collaboration. I wrote : I want to **really** thank you. This thread is great and show the power of collaboration. We all stronger and better. Thanks again.

Oct. 11, 2015

Re: [Pharo-dev] [ Zn+Zdc ] Implementation of HTTPS proxying using HTTP CONNECT tunneling

by stepharo

Big applaud :) TX!!!! Le 7/10/15 09:37, Sven Van Caekenberghe a Ã©crit : > Hi, > > Yesterday I did a first implementation of HTTPS proxying using HTTP CONNECT tunneling for Zn+Zdc, this should now be tested by a wider audience. With this new feature it should now be possible to access HTTPS Urls from behind an HTTP proxy. This is for all OS platforms. Thanks Nicolai for finding the spec reference and Torsten for the push. > > In Zn #bleedingEdge > > === > Name: Zinc-HTTP-SvenVanCaekenberghe.437 > Author: SvenVanCaekenberghe > Time: 6 October 2015, 9:57:35.790306 pm > UUID: 96b9026b-561e-4d6f-88b7-46389b163e99 > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.436 > > Implementation of HTTPS proxying using HTTP CONNECT tunneling > > https://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling > http://www.ietf.org/rfc/rfc2817.txt (section 5) > > Rewrite ZnClient>>#newConnectionTo: with delegate to newly added ZnClient>>#setupTLSTo: which implements the mechanism described in the links above > > Change ZnClient>>#readResponse: not to expect a body with a CONNECT request > > Change ZnHeaders>>#request: to use #authorityWithPort for the Host header > > Add ZnNetworkingUtils [class]>>#secureSocketStreamOn: > > Change ZnRequestLine>>#writeOn: to write the correct Request-URI portion of the Request-Line in case of CONNECT and/or plain HTTP(S) proxying > > Tested with Squid 3 as proxy > === > Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.54 > Author: SvenVanCaekenberghe > Time: 6 October 2015, 9:58:39.204572 pm > UUID: 134e875c-d2dd-4970-9697-b9d56833d77d > Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.53 > > Add ZnUrl>>#authorityWithPort and ZnUrl>>#hasSecureScheme > === > Name: Zinc-Tests-SvenVanCaekenberghe.234 > Author: SvenVanCaekenberghe > Time: 6 October 2015, 9:59:59.387302 pm > UUID: d2831cd8-fa01-4f44-8533-f5045dabbd7d > Ancestors: Zinc-Tests-SvenVanCaekenberghe.233 > > Modify ZnClientTests>>#testIfFailNonExistingHost because of different behavior when a proxy is involved > === > > On my machine all Zn+Zdc tests succeed with a proxy set (squid 3). Let's hope it works for others too. I did not yet test proxy authorization but I think it should work like before. > > An HTTP Proxy can be set in World > System > Settings > > Here is some code to do a simple test > > ZnClient new get: 'https://s3-eu-west-1.amazonaws.com/public-stfx-eu/test-2050.txt'. > > ZnClient new get: 'https://s3-eu-west-1.amazonaws.com/public-stfx-eu/small.html'. > > ZnClient new get: 'http://stfx.eu/small.html'. > > ZnNetworkingUtils default isProxySet. > > ZnNetworkingUtils shouldProxyUrl: 'https://s3-eu-west-1.amazonaws.com/public-stfx-eu/small.html' asUrl. > > Regards, > > Sven >

Oct. 11, 2015

Re: [Pharo-dev] why do we have XMLParser and XML in the default image?

by stepharo

In fact we just have the repositories defined. Le 11/10/15 10:41, stepharo a Ã©crit : > Hi > > why do we have XMLParser and XML in the default image? > > Stef > >

Oct. 11, 2015

why do we have XMLParser and XML in the default image?

by stepharo

Hi why do we have XMLParser and XML in the default image? Stef

Oct. 11, 2015

Re: [Pharo-dev] Yet another Athens font thread

by stepharo

Le 8/10/15 18:05, Aliaksei Syrel a Ã©crit : > Do you remember a hack with scaling? (scaleBy: 1.0001(a)1.0001) It makes > letters to have the same height, so no more huge ones with small > fonts. But it doesn't fix a bug when letters have wrong width so there > is a space between characters. The same effect can be achieved if we > set font size manually after setting scaled font before drawing glyphs > with cairo. It means that at some point we get wrong calculated > glyphs. So if we "fix" scaled font before glyph calculation - the > problem would be gone. In the patch I set scaled font, manually apply > font size, retrieve "fixed" scaled font and calculate glyphs based on it. > > Also after investigation I found something interesting. If we clean > real font of a logical font the problem gets fixed for some period of > time. I assume that FreeTypeFont gets broken after a while and logical > font always returns broken real font. Exactly. If you have code we applied accept it. In the pharo roadmaps on github you have a roadmap for the problems I identify. > Setting realFont to nil forces logical font to create a new working > free type font. As soon as new free type font is created cairo > produces scaled font and caches it. So actual problem lies deep in > FreeTypeFont... > > I even opened two images: one with broken fonts and one with working. > Then I compared in inspector two free type fonts - they are absolutely > the same and have identical instance variable in a whole object tree, > except of handler pointers to C structure which I can't inspect from > pharo... > > Saving image fixes fonts because of > > LogicalFont>>shutDown: quitting > self allSubInstances do: [:i | i clearRealFont]. > > > Cheers, > Alex > > On Thu, Oct 8, 2015 at 5:43 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > How did you fix it? > > Am 08.10.2015 17:06 schrieb "Aliaksei Syrel" <alex.syrel(a)gmail.com > <mailto:alex.syrel@gmail.com>>: > > Hi > > It looks like I fixed that weird text rendering problem... > Just get the latest Athens-Cairo. > > Cheers, > Alex > > On Mon, Aug 3, 2015 at 9:32 PM, Nicolai Hess > <nicolaihess(a)web.de> wrote: > > > > 2015-06-10 12:01 GMT+02:00 Aliaksei Syrel > <alex.syrel(a)gmail.com>: > > Hi > > I noticed that if I force use "Source Code Pro" as > standard font for all elements in the image I never > have problems with font rendering. In case of "Source > Sans Pro" font is just not usable becasue of rendering > bugs on mac, windows and linux(?). If "Lucida Sans > Pro" is used - no bugs too. > > Because bug is reproducable on all platform - it's > platform independent bug. > Because it's reproducable only with one specific font > - maybe it's not an athens issue but bug in font > itself and if someone could change/update Source Sans > Pro to a newly version or to a similar font the > problem will be solved? > > > Did you try to use a new font version ? > I don't know exactly how embedded fonts are included. I > tried to create the font with a newer version but it did > not work ( or at least I could not see any difference). > > > Cheers, > Alex > > > >

Oct. 11, 2015

Re: [Pharo-dev] [Slots] Slides from ESUG: Variables in Pharo5

by serge.stinckwich＠gmail.com

Great job Marcus ! I could not the SciSmalltalk talk. This was maybe not recorded ? Regards Sent from my iPhone > On 9 oct. 2015, at 17:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On Fri, Jul 17, 2015 at 3:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> The slides from the second talk are online: >> >> http://www.slideshare.net/MarcusDenker/variables-in-pharo5 > > > Video is finally online, too: > > Video Part1: https://www.youtube.com/watch?v=hEWKV9eWAGY > Video Part2: https://www.youtube.com/watch?v=hEWKV9eWAGY >

Oct. 11, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by stepharo

Hi stefna can you describe the problem so that we can ask alain? Stef Le 10/10/15 21:13, Stephan Eggermont a Ã©crit : > On 10-10-15 20:41, stepharo wrote: >> Hi stefan >> >> could you open a bug entry and publish a merge? >> We participated to an hackaton with esteban, pablo, kevin and cyril >> and we >> are not really happy about the tools, the frameworks... >> :( > > I can fix those. How do I check for (partially?) missing source code? > > Stephan > > > >

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by stepharo

Le 11/10/15 00:40, Dale Henrichs a Ã©crit : > Christophe, > > I still don't have a lot of time to read the paper and try to > understand what you are trying to accomplish, you should read it. :) We wrote it for that and it is not boring nor long. > but I am curious how you think "package dependencies" will play with > git-based projects? > > In git-based repositories I don't think you have the same type of > dependency issues that one might have with monticello repositories --- > In a monticello repository you have a whole range of possible package > versions to pick from, but in a git-based repository the range of > package versions is fixed to those that are committed together so the > packages that are meant to work together are committed together. I think that this is only true for packages committed within the same repo. Now between porjects published in different repo you have to express them. I do not think that we all want to publish in the same repo and clone out everything. > > In the bootstrap scenario, you would only have one version per package > to choose from, so the packages that are meant to work together are > committed together .... > > I guess I don't know what you mean when you say: >> we want to decouple a released version of a package from the working >> copy of the package version description (implies the creation of a >> package repository + a web interface on top of it to promote/search >> packages). > Perhaps a description of the problem being solved would help me > understand. We want to be able to have a package market place where tools can grab dependencies without to load code and can compute the set of packages that should be loaded. When a package is released into the market: then it externalise its metadata so that a crawler can automatically build dependency graph and create specific distribution. Stef >> >> Le 6 oct. 2015 Ã 20:23, Dale Henrichs a Ã©crit : >> >>> >>> On 10/6/15 5:10 AM, stepharo wrote: >>>> >>>> Le 6/10/15 11:40, Stephan Eggermont a Ã©crit : >>>>> On 06-10-15 11:11, stepharo wrote: >>>>>> I will do a separate configuration of magritte seaside. >>>>> You need to load the correct groups. Separate configurations are a >>>>> bad practice and should be eliminated, not encouraged. >>>> I totally disagree. >>>> And groups are not supported by the configurationBrowser >>>>> The configuration has a lot of essential complexity, as many >>>>> different combinations of components are needed in different >>>>> situations. We need tools that recognize that essential complexity >>>>> and support it, not tools that try to hide it and then have no >>>>> practical usability. >>>> Well I disagree. And all the effort of christophe for the new >>>> dependencies declarations at the package level just goes in that >>>> direction. >>>> I will do a MagritteSeaside Configuration that I will maintain and >>>> I will also do a MagritteTutorial one. >>>> >>> Stef, >>> >>> I hope you and Christophe are considering cross platform >>> considerations when implementing "new dependencies declarations at >>> the package level" ... MonticelloConfigurations had "package level >>> dependencies" and the implementation was extremely rigid to the >>> point where it wasn't possible to substitute an alternate >>> (platform-speicific) package in the package graph without creating >>> new package versions of all packages in the graph ... Of course I am >>> not aware of the approach that Christophe, but be aware that "there >>> be dragons there":) >> Thanks for the warning. cross-platform packages are integrated into >> this new approach by allowing to express dependencies to virtual >> packages (idea from debian OS: >> http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg) It >> allows low-coupling and is very flexible. >> You will find more information in the paper published at IWST'14: >> https://hal.inria.fr/hal-01086083/document (by the way, you should >> already have it, I sent it to you last year but you were very busy at >> this time ;) ) >> >> To summarize in a few words, we want dependencies expressed at the >> package level (and we want more meta-data on packages), we want to >> decouple a released version of a package from the working copy of the >> package version description (implies the creation of a package >> repository + a web interface on top of it to promote/search packages). >> We also want to detect dependencies automatically as much as possible >> to avoid missing or not-used dependencies (dependency analyser tool). >> All together, it will allow to define architectural rules and layers >> in Pharo. I now experimenting all that with the Pharo bootstrap. >> >> If you have any question or remark, do not hesitate to ask or to give >> feedback. >> >> Christophe. > > >

Oct. 11, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

Christophe, I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, but I am curious how you think "package dependencies" will play with git-based projects? In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... I guess I don't know what you mean when you say: > we want to decouple a released version of a package from the working > copy of the package version description (implies the creation of a > package repository + a web interface on top of it to promote/search > packages). Perhaps a description of the problem being solved would help me understand. Dale On 10/6/15 11:47 PM, Christophe Demarey wrote: > Hi Dale, > > Le 6 oct. 2015 Ã 20:23, Dale Henrichs a Ã©crit : > >> >> On 10/6/15 5:10 AM, stepharo wrote: >>> >>> Le 6/10/15 11:40, Stephan Eggermont a Ã©crit : >>>> On 06-10-15 11:11, stepharo wrote: >>>>> I will do a separate configuration of magritte seaside. >>>> You need to load the correct groups. Separate configurations are a bad practice and should be eliminated, not encouraged. >>> I totally disagree. >>> And groups are not supported by the configurationBrowser >>>> The configuration has a lot of essential complexity, as many different combinations of components are needed in different situations. We need tools that recognize that essential complexity and support it, not tools that try to hide it and then have no practical usability. >>> Well I disagree. And all the effort of christophe for the new dependencies declarations at the package level just goes in that direction. >>> I will do a MagritteSeaside Configuration that I will maintain and I will also do a MagritteTutorial one. >>> >> Stef, >> >> I hope you and Christophe are considering cross platform considerations when implementing "new dependencies declarations at the package level" ... MonticelloConfigurations had "package level dependencies" and the implementation was extremely rigid to the point where it wasn't possible to substitute an alternate (platform-speicific) package in the package graph without creating new package versions of all packages in the graph ... Of course I am not aware of the approach that Christophe, but be aware that "there be dragons there":) > Thanks for the warning. cross-platform packages are integrated into this new approach by allowing to express dependencies to virtual packages (idea from debian OS: http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg) It allows low-coupling and is very flexible. > You will find more information in the paper published at IWST'14: https://hal.inria.fr/hal-01086083/document (by the way, you should already have it, I sent it to you last year but you were very busy at this time ;) ) > > To summarize in a few words, we want dependencies expressed at the package level (and we want more meta-data on packages), we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). > We also want to detect dependencies automatically as much as possible to avoid missing or not-used dependencies (dependency analyser tool). All together, it will allow to define architectural rules and layers in Pharo. I now experimenting all that with the Pharo bootstrap. > > If you have any question or remark, do not hesitate to ask or to give feedback. > > Christophe.

Oct. 10, 2015

Missing mcz versions?

by Stephan Eggermont

Projects that load packages using Metacello, tend not to look in Pharo50 and Pharo50Inbox for new versions of those packages. I noticed the Rubric version in Moose 6 to be significantly behind the one in Pharo 5... Can we automatically copy back the inbox/integrator version to its repo? Stephan

Oct. 10, 2015

Re: [Pharo-dev] Problems with a large block

by Nicolai Hess

2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Hello Eliot, and thanks for your time. >> >> >> In our (pharo) implementation for sourceNodeForPC, we start at the >> AST-Node of >> the compiled method, get the IR (IntermediateRepresentation) and scan >> this sequence of IRNodes >> until we finally find that one, that maps to the bytecode of the closure >> creation code (this should be a IRPushClosureCopy). >> The problem is now, we don't find (always) the right IRNode, and it >> depens on the number of local temps, if this is > 3 we don't hit the right >> one. >> > > That's very strange. Can you construct a synthetic example of two simple > blocks, one with three temps and and one with four temps and show me the > difference in the byte code? > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" Bytecode 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <10> pushTemp: 0 21 <81 43> storeIntoTemp: 3 23 <81 42> storeIntoTemp: 2 25 <81 41> storeIntoTemp: 1 27 <7D> blockReturn 28 <7C> returnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" Bytecode 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <73> pushConstant: nil 21 <10> pushTemp: 0 22 <81 44> storeIntoTemp: 4 24 <81 43> storeIntoTemp: 3 26 <81 42> storeIntoTemp: 2 28 <81 41> storeIntoTemp: 1 30 <7D> blockReturn 31 <7C> returnTop As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: [ :x | | a b c | a:=b:=c:=x ] "bytecodeOffset -> IR" 19->pushClosureCopyCopiedValues: #() args: #(#x) 28->returnTop 20->pushTemp: #x 22->storeTemp: #c 24->storeTemp: #b 26->storeTemp: #a 27->blockReturnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "bytecodeOffset -> IR" 20->pushClosureCopyCopiedValues: #() args: #(#x) 31->returnTop 21->pushTemp: #x 23->storeTemp: #d 25->storeTemp: #c 27->storeTemp: #b 29->storeTemp: #a 30->blockReturnTop Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) For the first block, this works bytecodeOffset 19 = 16 - (-3) For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the second block this is one greater. > And my interpretation was, the IRPushClosureCopy node has the wrong >> "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >> depends on the number of local temps, but maybe this is right (for >> whatever this is used) and we are just using it wrong for in this situation. >> > > So you need to ask Marcus how to interpret bytecodeOffset. The thing is, > it should be simple. One has: > > BlockCreationBytecode > any number of pushConstant: nil's (0 to N) > first byte code in block > last bytecode in block (always a blockReturnTop) > > and a block's startup is always that of the byte immediately following the > BlockCreationBytecode. So if the byte code offset is somehow the span of > the "any number of pushConstant: nil's (0 to N)" then there's a bug in the > IR somewhere when the number of temps is > 3. But if that's not what it > means then, well, I don't know what the problem is. > >

Oct. 10, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by Stephan Eggermont

On 10-10-15 20:41, stepharo wrote: > Hi stefan > > could you open a bug entry and publish a merge? > We participated to an hackaton with esteban, pablo, kevin and cyril and we > are not really happy about the tools, the frameworks... > :( I can fix those. How do I check for (partially?) missing source code? Stephan

Oct. 10, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by stepharo

Hi stefan could you open a bug entry and publish a merge? We participated to an hackaton with esteban, pablo, kevin and cyril and we are not really happy about the tools, the frameworks... :( Le 10/10/15 10:38, Stephan Eggermont a Ã©crit : > On 10-10-15 10:28, Stephan Eggermont wrote: >> >> RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement >> >> RubFloatingEditorBuilder class>>exampleCommandLauncher >> >> RubFloatingEditorBuilder class>>exampleEditableStringMorph >> > > In Inbox theer are two 285s, and changes from Alain were not merged > > Stephan > > >

Oct. 10, 2015

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

by Yuriy Tymchuk

I do not remember the causes under first question. Something was broken and some layouts were not working. Iâve made a heavy usage of classes that align all elements alone some pane, and they were removed from RoassalWoden, so I have to add them as my own classes. Also Iâve added a lot of helper methods to the bounding box class, like getting its corrections. Secondly itâs not really an issue of Woden but more of the way Iâve designed ViDI. There is actually no such thing as a âcity layoutâ. If you take a look at the latest CodeCity by Ricky, there are plenty layouts (like rectangle packing, grid, wall, stack) and a nice way to compost them. Now besides having this functionality I also wanted to be able to dynamically change the view i.e. method getâs deleted, visualization is re-layedout. Thatâs why I have a custom âBuildingâ classes, that know their bricks (methods) and can lay them out and inform the parent container if the bonds were changed. The point is that ViDI should not be restricted only to 3D so I donât want to code all the re-layout logic into 3D subclasses. I think that at the moment I can just port orbiting controls to the old Roassal3D. Maybe in the future I will have time to create ViDI v2. Or maybe Iâll find a student willing to do that :) Uko > On 10 Oct 2015, at 13:18, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Yes, I would like to understand why you cannot migrate to woden > Alexandre > > Le 10 oct. 2015 Ã 04:55, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> a Ã©crit : > >> >> >> Le 9/10/15 19:59, Yuriy Tymchuk a Ã©crit : >>> 2 reasons: >>> >>> 1) something is always incompatible (Iâve tried 2 times already) >>> 2) I have too many things hardcoded in Roassal3D subclasses. I have to move it into a proper model, and this will take time. >> >> >> Alex you should have a look at the missing hooks mentioned by Yuriy because I'm quite sure that other >> people will have the same problems and this is not good to duplicate effort. >> >> Yiriy can you point alex to the hardcoded points? >> >>> >>> Iâll take a look at the Orbiter. Although as far as I remember Roassal3D and Woden have different interfaces. >>> >>> Cheers. >>> Uko >>> >>> >>>> On 09 Oct 2015, at 19:54, Alexandre Bergel < <mailto:alexandre.bergel@me.com>alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>>> >>>> Ah sorry. >>>> Teseo has written the class OrbitController. I think you should be able to reuse it for Roassal3d Old. But why not trying to migrate to Woden instead? >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Oct 9, 2015, at 2:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>> >>>>> No, the control the interaction that moves you around the object when you drag mouse instead of "rotating your headâ as in fps game. >>>>> >>>>> Uko >>>>> >>>>> >>>>>> On 09 Oct 2015, at 19:11, Alexandre Bergel < <mailto:alexandre.bergel@me.com>alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>>>>> >>>>>> By flyover you mean having a text tooltip? >>>>>> >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel <http://www.bergel.eu/>http://www.bergel.eu <http://www.bergel.eu/> >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 9, 2015, at 12:40 PM, Yuriy Tymchuk < <mailto:yuriy.tymchuk@me.com>yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>>>> >>>>>>> No, honestly Iâd really appreciate if someone can help me to add this flyover interaction to ViDI, so we can run some kind of controlled experiment on it (and for now itâs not an option to move ViDI to Woden). >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >>> >>

Oct. 10, 2015

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

by Alexandre Bergel

Yes, I would like to understand why you cannot migrate to woden Alexandre > Le 10 oct. 2015 Ã 04:55, stepharo <stepharo(a)free.fr> a Ã©crit : > > > > Le 9/10/15 19:59, Yuriy Tymchuk a Ã©crit : >> 2 reasons: >> >> 1) something is always incompatible (Iâve tried 2 times already) >> 2) I have too many things hardcoded in Roassal3D subclasses. I have to move it into a proper model, and this will take time. > > > Alex you should have a look at the missing hooks mentioned by Yuriy because I'm quite sure that other > people will have the same problems and this is not good to duplicate effort. > > Yiriy can you point alex to the hardcoded points? > >> >> Iâll take a look at the Orbiter. Although as far as I remember Roassal3D and Woden have different interfaces. >> >> Cheers. >> Uko >> >> >>> On 09 Oct 2015, at 19:54, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Ah sorry. >>> Teseo has written the class OrbitController. I think you should be able to reuse it for Roassal3d Old. But why not trying to migrate to Woden instead? >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>>> On Oct 9, 2015, at 2:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> No, the control the interaction that moves you around the object when you drag mouse instead of "rotating your headâ as in fps game. >>>> >>>> Uko >>>> >>>> >>>>> On 09 Oct 2015, at 19:11, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>> >>>>> By flyover you mean having a text tooltip? >>>>> >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>>> On Oct 9, 2015, at 12:40 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>>> >>>>>> No, honestly Iâd really appreciate if someone can help me to add this flyover interaction to ViDI, so we can run some kind of controlled experiment on it (and for now itâs not an option to move ViDI to Woden). >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

Oct. 10, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by Stephan Eggermont

On 10-10-15 10:28, Stephan Eggermont wrote: > > RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement > > RubFloatingEditorBuilder class>>exampleCommandLauncher > > RubFloatingEditorBuilder class>>exampleEditableStringMorph > In Inbox theer are two 285s, and changes from Alain were not merged Stephan

Oct. 10, 2015

50378 -> builds need to be redone?

by Stephan Eggermont

RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement RubFloatingEditorBuilder class>>exampleCommandLauncher RubFloatingEditorBuilder class>>exampleEditableStringMorph

Oct. 10, 2015

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

by stepharo

Le 9/10/15 19:59, Yuriy Tymchuk a Ã©crit : > 2 reasons: > > 1) something is always incompatible (Iâve tried 2 times already) > 2) I have too many things hardcoded in Roassal3D subclasses. I have to > move it into a proper model, and this will take time. Alex you should have a look at the missing hooks mentioned by Yuriy because I'm quite sure that other people will have the same problems and this is not good to duplicate effort. Yiriy can you point alex to the hardcoded points? > > Iâll take a look at the Orbiter. Although as far as I remember > Roassal3D and Woden have different interfaces. > > Cheers. > Uko > > >> On 09 Oct 2015, at 19:54, Alexandre Bergel <alexandre.bergel(a)me.com >> <mailto:alexandre.bergel@me.com>> wrote: >> >> Ah sorry. >> Teseo has written the class OrbitController. I think you should be >> able to reuse it for Roassal3d Old. But why not trying to migrate to >> Woden instead? >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Oct 9, 2015, at 2:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >>> <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> No, the control the interaction that moves you around the object >>> when you drag mouse instead of "rotating your headâ as in fps game. >>> >>> Uko >>> >>> >>>> On 09 Oct 2015, at 19:11, Alexandre Bergel <alexandre.bergel(a)me.com >>>> <mailto:alexandre.bergel@me.com>> wrote: >>>> >>>> By flyover you mean having a text tooltip? >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Oct 9, 2015, at 12:40 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >>>>> <mailto:yuriy.tymchuk@me.com>> wrote: >>>>> >>>>> No, honestly Iâd really appreciate if someone can help me to add >>>>> this flyover interaction to ViDI, so we can run some kind of >>>>> controlled experiment on it (and for now itâs not an option to >>>>> move ViDI to Woden). >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

Oct. 10, 2015

Re: [Pharo-dev] Smalltalkhub instable

by stepharo

do we have a document to show how to do such reboot? Le 7/10/15 16:55, Marcus Denker a Ã©crit : > >> On 07 Oct 2015, at 15:47, Blondeau Vincent >> <vincent.blondeau(a)worldline.com >> <mailto:vincent.blondeau@worldline.com>> wrote: >> >> Hi, >> It is very hard to work because Smalltalkhub is very instable today. >> I wanted to launchhttps://ci.inria.fr/moose/job/moose-6.0but I get >> either an 400 or 500 errorâ¦ (It seems to work now but for how long?) >> Can somebody could look at this issue ? > I restarted apacheâ¦which seems to be the source of the problem when > loading static files makes problems. > > Marcus >

Oct. 10, 2015

50378 broke source

by Stephan Eggermont

I found it in 50379, but it was introduced in 50378. 50377 looks ok. The FTSearch is fixed in 50380 RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement RubFloatingEditorBuilder class>>exampleCommandLauncher RubFloatingEditorBuilder class>>exampleEditableStringMorph Stephan

Oct. 9, 2015

Re: [Pharo-dev] Yet another Athens font thread

by Aliaksei Syrel

No, they are needed. Because glyphs must be calculated (getGlyphs:of:) after(!) setting font size. Otherwise there are huge gaps between characters. When font problem appears, some characters are of size 14 even if font size 10. So glyphs of big characters have larger extent as it should be. In your example you set font size and fix font, so all characters are rendered correctly, but at wrong positions. That is a source of unnecessary gaps. Thete is a way to break font: 1) Get new pharo image 2) Get Bloc 3) Switch to bloc 4) remove all morphs 5) save and quite 6) open image 7) open nautilus Do something to fix font. Repeat 4-7. If fix is "fake" fonts will be broken.. On Oct 9, 2015 10:31 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: > > > 2015-10-08 18:05 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > >> Do you remember a hack with scaling? (scaleBy: 1.0001(a)1.0001) It makes >> letters to have the same height, so no more huge ones with small fonts. But >> it doesn't fix a bug when letters have wrong width so there is a space >> between characters. The same effect can be achieved if we set font size >> manually after setting scaled font before drawing glyphs with cairo. It >> means that at some point we get wrong calculated glyphs. So if we "fix" >> scaled font before glyph calculation - the problem would be gone. In the >> patch I set scaled font, manually apply font size, retrieve "fixed" scaled >> font and calculate glyphs based on it. >> >> Also after investigation I found something interesting. If we clean real >> font of a logical font the problem gets fixed for some period of time. I >> assume that FreeTypeFont gets broken after a while and logical font always >> returns broken real font. Setting realFont to nil forces logical font to >> create a new working free type font. As soon as new free type font is >> created cairo produces scaled font and caches it. So actual problem lies >> deep in FreeTypeFont... >> >> I even opened two images: one with broken fonts and one with working. >> Then I compared in inspector two free type fonts - they are absolutely the >> same and have identical instance variable in a whole object tree, except of >> handler pointers to C structure which I can't inspect from pharo... >> >> Saving image fixes fonts because of >> >>> LogicalFont>>shutDown: quitting >>> self allSubInstances do: [:i | i clearRealFont]. >> >> >> Cheers, >> Alex >> > > This is great. > > I looked at your change. And noticed the call to > setFontSize > this was never called until now. Maybe this was the problem. > > Now, I just changed > > renderGlyphs: cairoGlyphs > > font lock. > canvas > setPathMatrix; > setScaledFont: font; > setFontSize: originalFont pixelSize. "<< new " > canvas paint loadOnCairoCanvas: canvas. > > canvas showGlyphs: cairoGlyphs address size: cairoGlyphs size. > font unlock. > > And it seems the font issue is gone. Maybe the other changes (set and get > scaled font in #glyphsOf:from:to: ) > isn't needed? (needs more tests) > > > >> On Thu, Oct 8, 2015 at 5:43 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> How did you fix it? >>> Am 08.10.2015 17:06 schrieb "Aliaksei Syrel" <alex.syrel(a)gmail.com>: >>> >>>> Hi >>>> >>>> It looks like I fixed that weird text rendering problem... Just get the >>>> latest Athens-Cairo. >>>> >>>> Cheers, >>>> Alex >>>> >>>> On Mon, Aug 3, 2015 at 9:32 PM, Nicolai Hess <nicolaihess(a)web.de> >>>> wrote: >>>> >>>>> >>>>> >>>>> 2015-06-10 12:01 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >>>>> >>>>>> Hi >>>>>> >>>>>> I noticed that if I force use "Source Code Pro" as standard font for >>>>>> all elements in the image I never have problems with font rendering. In >>>>>> case of "Source Sans Pro" font is just not usable becasue of rendering bugs >>>>>> on mac, windows and linux(?). If "Lucida Sans Pro" is used - no bugs too. >>>>>> >>>>>> Because bug is reproducable on all platform - it's platform >>>>>> independent bug. >>>>>> Because it's reproducable only with one specific font - maybe it's >>>>>> not an athens issue but bug in font itself and if someone could >>>>>> change/update Source Sans Pro to a newly version or to a similar font the >>>>>> problem will be solved? >>>>>> >>>>> >>>>> Did you try to use a new font version ? >>>>> I don't know exactly how embedded fonts are included. I tried to >>>>> create the font with a newer version but it did not work ( or at least I >>>>> could not see any difference). >>>>> >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> Alex >>>>>> >>>>> >>>>> >>>> >> >

Oct. 9, 2015