On 30/03/2018 22:30, Stephane Ducasse wrote:
> Hi
>
> Today during the Pharo sprint I went over all the deprecated methods
> in Pharo 70 and Pharo 60 and I checked if I could convert the
> deprecated ones into deprecated:transformWith: so that the conversion
> is done automatically to help people
Hi Eliot,
On Fri, Mar 30, 2018 at 12:57:25PM -0700, Eliot Miranda wrote:
> Hi Alistair,
>
> > On Mar 30, 2018, at 7:57 AM, Alistair Grant wrote:
> >
> > Hi Damien,
> >
> >> On 30 March 2018 at 14:59, Damien Pollet wrote:
> >> The class Path from FileSystem is documented as private??? but it s
Hi Damien,
On Fri, Mar 30, 2018 at 05:30:52PM +0200, Damien Pollet wrote:
> I understand that when you want to actually open and read/write files, you
> have
> to resolve them in a filesystem and that's what a FileReference is for.
>
> But there are uses for file paths BEFORE you have a filesyst
Stephane Ducasse-3 wrote
> …The way we will be able to support a
> smoother conversion to more recent version.
Awesome!!! Can't wait to take a look…
-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
There is a new Pharo build available!
The status of the build #745 was: SUCCESS.
The Pull Request #1166 was integrated:
"21661-Should-add-a-test-and-rescue-Point--scaleTo-"
Pull request url: https://github.com/pharo-project/pharo/pull/1166
Issue Url: https://pharo.fogbugz.com/f/cases/21
There is a new Pharo build available!
The status of the build #744 was: SUCCESS.
The Pull Request #1165 was integrated: "21653 - ShiftClassInstaller gives error
when changing superclass to new one with variables"
Pull request url: https://github.com/pharo-project/pharo/pull/1165
Issue U
Hi
Today during the Pharo sprint I went over all the deprecated methods
in Pharo 70 and Pharo 60 and I checked if I could convert the
deprecated ones into deprecated:transformWith: so that the conversion
is done automatically to help people migrating from one version to the
other.
I also collecte
Hi Alistair,
> On Mar 30, 2018, at 7:57 AM, Alistair Grant wrote:
>
> Hi Damien,
>
>> On 30 March 2018 at 14:59, Damien Pollet wrote:
>> The class Path from FileSystem is documented as private… but it should be
>> public, shouldn't it?
>>
>> First hint is that it's named with a public name: (
There is a new Pharo build available!
The status of the build #743 was: SUCCESS.
The Pull Request #1164 was integrated:
"21438-There-is-code-in-_UnpackagedPackage-in-Pharo-7"
Pull request url: https://github.com/pharo-project/pharo/pull/1164
Issue Url: https://pharo.fogbugz.com/f/cases/
I agree with you damien. This is the experience we are facing with pillar.
Manipulating fileReference is what pillar is doing and this is bad.
In addition the API of FileSystem is missing operations
using path such as copying a sub structure from a given level or path
to another structure at a dif
I understand that when you want to actually open and read/write files, you
have to resolve them in a filesystem and that's what a FileReference is for.
But there are uses for file paths BEFORE you have a filesystem to resolve
them in.
I was talking about a config file, in which some values are fi
Hi Damien,
On 30 March 2018 at 14:59, Damien Pollet wrote:
> The class Path from FileSystem is documented as private… but it should be
> public, shouldn't it?
>
> First hint is that it's named with a public name: (Path not FileSystemPath).
>
> Then, consider the following use-case : if you have a
Cool, thanks a lot.
On Fri, Mar 30, 2018 at 4:06 PM, K K Subbu wrote:
> On Friday 30 March 2018 06:12 PM, teso...@gmail.com wrote:
>
> 32 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p
>> ull%20request%20and%20branch%20Pipeline/view/change-
>> requests/job/PR-1142/lastSuccess
On Friday 30 March 2018 06:12 PM, teso...@gmail.com wrote:
32 bits:
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-1142/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-b8d360a.zip
64 bits:
https://ci.
The class Path from FileSystem is documented as private… but it should be
public, shouldn't it?
First hint is that it's named with a public name: (Path not FileSystemPath).
Then, consider the following use-case : if you have a file name in some
config file (.ini, .toml…) then that's really a Path
Thanks a lot.
On Fri, Mar 30, 2018 at 2:55 PM, Cyril Ferlicot D. wrote:
> Le 30/03/2018 à 14:42, teso...@gmail.com a écrit :
> > I have implemented the backend of FreeType using only FFI calls.
> > So the whole implementation is in the image side, the current plugin has
> > a lot of problems han
Le 30/03/2018 à 14:42, teso...@gmail.com a écrit :
> I have implemented the backend of FreeType using only FFI calls.
> So the whole implementation is in the image side, the current plugin has
> a lot of problems handling the release of the pointers. The new
> implementation is using the mechanism
I have implemented the backend of FreeType using only FFI calls.
So the whole implementation is in the image side, the current plugin has a
lot of problems handling the release of the pointers. The new
implementation is using the mechanism that is already present in UFFI to
release the Heap pointer
Hi
I do not really understand why fromShortVErsionString: and friends
have been deprecated (that part I can understand) but why do they depend
on an extension packaged in tests.
Stef
There is a new Pharo build available!
The status of the build #742 was: SUCCESS.
The Pull Request #1163 was integrated:
"21653-ShiftClassInstaller-gives-error-when-changing-superclass-to-new-one-with-variables"
Pull request url: https://github.com/pharo-project/pharo/pull/1163
Issue Url
20 matches
Mail list logo
