- Pharo-dev - lists.pharo.org

Re: About / and ZnUrl

by Sven Van Caekenberghe

Because ZnUrl>>#/ is pretty simple and not very intelligent. It is meant for path extension. Read the code if you are curious. What you probably want is ZnUrl>>#withRelativeReference: 'http://www.pharo.org/figures/' asUrl withRelativeReference: '/documentation/p.png'. "http://www.pharo.org/documentation/p.png" This implementation is based on an actual specification [RFC 3986 Section 5] with a big test suite. But it might still surprise you. It seems to work best when the base URL (the left one) points to an actual document (the current HTTP page) and the relative URL (the right one) is meant to refer from there. See the method comment and #testReferenceResolution. Sven > On 5 Sep 2021, at 22:01, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi sven > > may be you know the answer :) > > > 'http://www.pharo.org/figures/' asUrl / 'documentation/p.png' > "http://www.pharo.org/figures/documentation/p.pngâ > > so far so good. > > > 'http://www.pharo.org/figures/' asUrl / '/documentation/p.png' > "http://www.pharo.org/figures//documentation/p.png" > > Why not having > > "http://www.pharo.org/documentation/p.pngâ > > Because /documentation is absolute so the resolution could take that into account. > > S

Sept. 5, 2021

About / and ZnUrl

by stephane ducasse

Hi sven may be you know the answer :) 'http://www.pharo.org/figures/' asUrl / 'documentation/p.png' "http://www.pharo.org/figures/documentation/p.pngâ so far so good. 'http://www.pharo.org/figures/' asUrl / '/documentation/p.png' "http://www.pharo.org/figures//documentation/p.png" Why not having "http://www.pharo.org/documentation/p.pngâ Because /documentation is absolute so the resolution could take that into account. S

Sept. 5, 2021

This week (35/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 26 Pull Requests and closed 15 Issue tracker entries this week. Focus for Pharo10 is still cleaning up unused code. Features ======== - Adding initial iteration of ExternalProjectLoader #9827 https://github.com/pharo-project/pharo/pull/9827 - 9848-Allow-reflective-execution-of-CompiledMethod-without-sending-to-the-receiver #9849 https://github.com/pharo-project/pharo/pull/9849 Fixes ===== - Make printing of BlockClosure more robust #9843 https://github.com/pharo-project/pharo/pull/9843 - 9731-Ph9-Spec2-List-items-cannot-be-selected-when-medium-font-is-used #9852 https://github.com/pharo-project/pharo/pull/9852 Dead code cleanup ================= - Cleanup-deprecated-classify #9837 https://github.com/pharo-project/pharo/pull/9837 - remove-deprecated-code-08-30 #9862 https://github.com/pharo-project/pharo/pull/9862 - Cleanup-Deprecated-Code-09-01 #9876 https://github.com/pharo-project/pharo/pull/9876 - Cleanup-Deprecated-09-02 #9886 https://github.com/pharo-project/pharo/pull/9886 - AthensCairoStrokePaint>>#initialize not necessary #9867 https://github.com/pharo-project/pharo/pull/9867 - Cleanup #isActivePlatform #9865 https://github.com/pharo-project/pharo/pull/9865 - Remove UnixEnvironment>>#unsetEnv: #9875 https://github.com/pharo-project/pharo/pull/9875 - Metaclass>>#sharedPools can be removed #9869 https://github.com/pharo-project/pharo/pull/9869 - 9878-detectSum-is-deprecated-but-still-has-users #9884 https://github.com/pharo-project/pharo/pull/9884 - Cleanup-Deprecated-DisplayMedium #9880 https://github.com/pharo-project/pharo/pull/9880 - Cleanup FileSystemDirectoryEntry #9873 https://github.com/pharo-project/pharo/pull/9873 Cleanups ======== - Simpler-VariableName-ReservedVariable #9841 https://github.com/pharo-project/pharo/pull/9841 - Deprecate-DebuggerMethodMapOpal #9824 https://github.com/pharo-project/pharo/pull/9824 - Unify #layoutForType: with the #kind methods. #9819 https://github.com/pharo-project/pharo/pull/9819 - 9681-AbstractLayout-hierarchy-unify-typeOfClass-and-kind #9861 https://github.com/pharo-project/pharo/pull/9861 - EmbeddedFreeTypeFontInstaller class >> initialize should not do a supâ¦ #9855 https://github.com/pharo-project/pharo/pull/9855 - Cleaning up ValueLink objects #9799 https://github.com/pharo-project/pharo/pull/9799 - categorize-more-09-01 #9881 https://github.com/pharo-project/pharo/pull/9881 Documentation ============== - Expand Dictionary documentation #9834 https://github.com/pharo-project/pharo/pull/9834 - Add EmbeddedFreeTypeFontDescription class comment #9860 https://github.com/pharo-project/pharo/pull/9860 - Fix #9788 : Change parameter from class to string #9842 https://github.com/pharo-project/pharo/pull/9842 Pharo9 ====== - Backport Issue 9731: Ph9-Spec2-List-items-cannot-be-selected-when-medium-font-is-used #9853 https://github.com/pharo-project/pharo/pull/9853

Sept. 3, 2021

Re: about URL isAbsolute

by stephane ducasse

Hi sven thank you for the time you spent replying to me :) > Yes, this is confusing. > > The first 2 forward slashed are part of the scheme, file:// or http:// > > Next comes the host:port, but that does not make too much sense for a File URL. > > Finally comes the path. > > For the syntax to make sense, you need a third / (to indicate that there is no host:port). > > If you inspect the ZnUrl object in your second example, 'file://toto.png <file://toto.png/>' asUrl, you will see that is has toto.png as host, not as path. This is in fact an invalid File URL. > > The annoying thing is, there is no such thing as a relative File URL. Yes I considered that a fully formed (with http as scheme) is always absolute. > > https://en.wikipedia.org/wiki/File_URI_scheme <https://en.wikipedia.org/wiki/File_URI_scheme> > > Now, for your problem, I would not allow the use of file:// there, and just simpler file references (using #asFileReference), which can be relative. Good suggestion I will do that. > > Sven > > PS: Also, the methods #isAbsolute and #isRelative do not make much sense on ZnUrl, see the method comment/implementation. I was experimenting more during a meeting :) 'figures/image.png' asFileReference asResolvedBy: FileSystem memory / 'docs' >>> "memory:///docs/figures/image.png <memory:///docs/figures/image.png>" Which is what I want but this is for file reference. And file Reference are not polymorphic to url. 'figures/image.png' asUrl asFileReference asResolvedBy: FileSystem memory / 'docs' Do you think it would be possible to get the best of both worlds? ZnUrl >> asFileReference "Convert the receiver into a new FileReference object. Note that for a FileReference a trailing slash is not relevant" | path | self assert: self scheme = #file description: 'Only a file:// URL can be converted to a FileReference'. self isSlash ifTrue: [ ^ FileSystem root ]. path := self isDirectoryPath ifTrue: [ segments allButLast ] ifFalse: [ segments copy ]. ^ FileReference fileSystem: FileSystem disk path: (AbsolutePath withAll: path) Removing the assert: would makes my life easier. Even if it returns an absolute path while 'figures/image.pngâ is a relative one. Else I can copy and paste asFileReference and create my own. S > On 31 Aug 2021, at 16:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Stef, > > Yes, this is confusing. > > The first 2 forward slashed are part of the scheme, file:// or http:// > > Next comes the host:port, but that does not make too much sense for a File URL. > > Finally comes the path. > > For the syntax to make sense, you need a third / (to indicate that there is no host:port). > > If you inspect the ZnUrl object in your second example, 'file://toto.png' asUrl, you will see that is has toto.png as host, not as path. This is in fact an invalid File URL. > > The annoying thing is, there is no such thing as a relative File URL. > > https://en.wikipedia.org/wiki/File_URI_scheme > > Now, for your problem, I would not allow the use of file:// there, and just simpler file references (using #asFileReference), which can be relative. > > Sven > > PS: Also, the methods #isAbsolute and #isRelative do not make much sense on ZnUrl, see the method comment/implementation. > >> On 31 Aug 2021, at 14:54, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Hi >> >> Iâm a bit confused. When I use isAbsolute I get >> >> 'file:///toto.png' asUrl isAbsolute >>>>> false >> >> >> 'file://toto.png' asUrl isAbsolute >>>>> true >> >> >> Now I confused because as Unix / is absolute so file://toto.png would be relative. >> and /foo is absolute. >> >> Are URLs so different than files? >> Are the results I get correct? >> >> I ask this question in the context of Microdown if people write >> >> ![caption](file://toto.png). >> ![caption](figures/toto.png) >> ![caption](file:///toto.png). >> >> S >> >>

Aug. 31, 2021

Re: about URL isAbsolute

by Sven Van Caekenberghe

Stef, Yes, this is confusing. The first 2 forward slashed are part of the scheme, file:// or http:// Next comes the host:port, but that does not make too much sense for a File URL. Finally comes the path. For the syntax to make sense, you need a third / (to indicate that there is no host:port). If you inspect the ZnUrl object in your second example, 'file://toto.png' asUrl, you will see that is has toto.png as host, not as path. This is in fact an invalid File URL. The annoying thing is, there is no such thing as a relative File URL. https://en.wikipedia.org/wiki/File_URI_scheme Now, for your problem, I would not allow the use of file:// there, and just simpler file references (using #asFileReference), which can be relative. Sven PS: Also, the methods #isAbsolute and #isRelative do not make much sense on ZnUrl, see the method comment/implementation. > On 31 Aug 2021, at 14:54, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi > > Iâm a bit confused. When I use isAbsolute I get > > 'file:///toto.png' asUrl isAbsolute > >>> false > > > 'file://toto.png' asUrl isAbsolute > >>> true > > > Now I confused because as Unix / is absolute so file://toto.png would be relative. > and /foo is absolute. > > Are URLs so different than files? > Are the results I get correct? > > I ask this question in the context of Microdown if people write > > ![caption](file://toto.png). > ![caption](figures/toto.png) > ![caption](file:///toto.png). > > S > >

Aug. 31, 2021

about URL isAbsolute

by stephane ducasse

Hi Iâm a bit confused. When I use isAbsolute I get 'file:///toto.png' asUrl isAbsolute >>> false 'file://toto.png' asUrl isAbsolute >>> true Now I confused because as Unix / is absolute so file://toto.png <file:///toto.png> would be relative. and /foo is absolute. Are URLs so different than files? Are the results I get correct? I ask this question in the context of Microdown if people write ![caption](file://toto.png). ![caption](figures/toto.png) ![caption](file:///toto.png). S

Aug. 31, 2021

This week (34/2021) on the Pharo Issue tracker

by Marcus Denker

We merged 24 pull requests and closed 19 issues this week. The focus right now is cleaning up unused code. The image got already smaller! Immutable Litarals / Literal Sharing ================================== We compile literals as immutable objects already in Pharo9, this is now improved: Literal arrays are now recursively read-only, the compiler preference was removed and we have some first code (not used yet) to share all the equal literals between methods (and literal arrays) so save a little bit of memory. - ReadOnlyLiterals-Remove-Preference #9793 https://github.com/pharo-project/pharo/pull/9793 - RecurseReadOnly-LiteralArray #9815 https://github.com/pharo-project/pharo/pull/9815 - LiteralSharing-NestedArrays #9836 https://github.com/pharo-project/pharo/pull/9836 Cleanups: Remove Dead Code ========================== One Focus of Pharo10 is to remove unused code. The Image got already smaller by around 5MB! This week we removed the old FFI and the old Event handlin code, besides smaller removals. - Removing old Event handling and VM World Renderer #9838 https://github.com/pharo-project/pharo/pull/9838 - Removing old ffi #9831 https://github.com/pharo-project/pharo/pull/9831 - Reduce-duplicated-Methods-2 #9789 https://github.com/pharo-project/pharo/pull/9789 - Refactoring2-Deprecation-Clean #9817 https://github.com/pharo-project/pharo/pull/9817 - DeadCode-Cleanup-08-24 #9816 https://github.com/pharo-project/pharo/pull/9816 - Cleanup-Deprecated-Metacello #9823 https://github.com/pharo-project/pharo/pull/9823 Tests ===== Keeping the CI tests green is work... - Fixing broken tests #9785 https://github.com/pharo-project/pharo/pull/9785 - 9795-Failing-on-CI-ReleaseTesttestNoEquivalentSuperclassMethods #9797 https://github.com/pharo-project/pharo/pull/9797 - Skip-testModifiedReturn #9802 https://github.com/pharo-project/pharo/pull/9802 - Improve testNoUncategorizedMethods #9808 https://github.com/pharo-project/pharo/pull/9808 - upgrading Pharo 10 with Roassal 0.9.9 #9801 https://github.com/pharo-project/pharo/pull/9801 - ReleaseTest-Timeout-Longer #9839 https://github.com/pharo-project/pharo/pull/9839 Cleanups ======== - Use Protocol unclassified whenever possible #9805 https://github.com/pharo-project/pharo/pull/9805 - SystemWindow>>#openInWorldExtent: should be in Deprecated10 package #9810 https://github.com/pharo-project/pharo/pull/9810 - Categorize some more uncategorized methods #9812 https://github.com/pharo-project/pharo/pull/9812 - Fix typos: boostrap -> bootstrap #9814 https://github.com/pharo-project/pharo/pull/9814 - Adding doc #9821 https://github.com/pharo-project/pharo/pull/9821 - Ring2: simplify #mcType and unify with #kind #9820 https://github.com/pharo-project/pharo/pull/9820 Features ======== - Loading documentation reader. #9818 https://github.com/pharo-project/pharo/pull/9818 - Exposing the ABI of a function to the image. #9826 https://github.com/pharo-project/pharo/pull/9826

Aug. 27, 2021

Two year engineer or postdoc position on Moose

by stephane ducasse

Hello We have a two year position for an engineer or postdoc position for supporting research activities on top of the Moose open-source platform. The RMOD team is about to transform itself into a new Team called Evref that is a joint team with a part of Berger-Levrault R&D department. Berger-Levrault is the 10th software developer french editor. In the context of the enhancement of the Moose platform, the selected candidate will contribute to one of several of the following topics: - The introduction of the process mechanism in the platform. Indeed, currently, the Moose platform enables the user to build her own metamodels, models, visualisations and so on. However, there is no process mechanism to help more the user in the analysis or the migration using the Moose platform. This work implies for example to define a model of flexible process and an architecture where the developper can easily define her own process from scratch or by adaptation of existing process. - The management of several versions of the same models. Currently, in the Moose platform each version is separated from the others. We have support in previous versions of Moose for example through Orion (ref). This works implies to define how to represent, manipulate and integrate in the Moose platform the management of several versions. It also implies to support the difference between models eventually conforming different metamodels and the evolution from one model to another. - The management of the software system representation through several models conforming different metamodels. All the models represent the same version of the software systems, but from different perspectives. For example, we may have a GUI model, a Database model and a software model. This work implies to be able to specify that a concept in one model is the same in another model. This will then enable us to propose specific analysis explaining how data are used and propagated in the software systems. Or it will also enable us to identify in the code the business concepts and thus to provide a more abstract model. - Decomposition of god classes from their clients. In practice, there exist different types of god classes. The ones that have several responsibilities materialised by a lot of attributes and methods using these attributes. The ones that have several responsibilities materialised by a lot of client classes invoking their classes. We already proposed support to decompose god classes of the first type (ref to ICSME2019). The work here consists to provide support for the second type. It means provide visualisation and possibly a process. There might be eventually other types or classes for which the type is a mixture of these two. It will be necessary to deal with those hybrid classes. - Operationalizable non-functional requirements. Currently, the non-functional requirements (NFR) are used to build a system, but it exists few approaches that enable the developer to identify them from the code by reverse engineering. However, we know that with time, software systems evolve and often without update of the documentation. Thus it is not clear that after time the non-functional requirements are still fulfilled by the software system. This work implies to be able to represent NFR, to support them in the Moose platform and propose NFR aware tools to manipulate the source code. Such tools will include: (1) tools to automatically detect security threats in the source code from software quality issues, (2) tools to support software engineers in understanding NFR (memory consumption, security, efficiency) and (3) tools to transform source code while preserving a NFR (such as security or efficiency). All this work will happen in interaction with Berger-Levrault collaboration. In addition, the possibility to have a permanent research position at the end of this contract with Berger-Levrault is part of the current contract. Salary is competitive and taken from french state grid. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 27, 2021

Re: About Pharo X nickname: "Cut the fat"

by Noury Bouraqadi

Wow! Impressive list! Well done! Noury

Aug. 26, 2021

About Pharo X nickname: "Cut the fat"

by stephane ducasse

Hi pharoers just a little email to tell you that we are super happy because we are in the situation to remove old, unused or part in love for retirement from Pharo. And we are doing this at the level of the image but also the VM. So far we removed GT Glamour Alien (under way) OldFFI (under way) Old byte code (on the way) Many Pharo 80 deprecated methods. We plan to remove Spec1 - finally Commander Refactorings in favor of Refactorings2 At the level of the VM Yesterday pablo fixed 1000 warnings We removed Newspeak support MT, old bytecode while fixing ephemerons, GC bugs, ... This is super important to travel light because it will let us be agile and faster. So if you see questionable code please let us know. We do not want to remove functionality but we want to make sure that we do not doublons. S.

Aug. 25, 2021