> On 13 Jul 2017, at 11:10, Sven Van Caekenberghe wrote:
>
> Hi,
>
> Like others I seem to have trouble loading GitHub repositories, in Pharo 4 in
> my case.
>
> Basically, the following fails:
>
> Metacello new
> baseline: 'P3';
> repositor
Hi,
Like others I seem to have trouble loading GitHub repositories, in Pharo 4 in
my case.
Basically, the following fails:
Metacello new
baseline: 'P3';
repository: 'github://svenvc/P3';
load.
But it also fails as dependency when specified like this:
baseline: 'P3' with: [
spec r
> On 8 Jul 2017, at 09:33, Clément Bera wrote:
>
> The incremental GC is already mentioned in "Better support for large heaps
> (GC tuning API, incremental GC)". Now we have a second paragraph about the
> incremental GC, that's redundant and the form of the paragraph is not
> consistent with
> On 6 Jul 2017, at 23:56, Eliot Miranda wrote:
>
> Hi Sven,
>
> On Thu, Jul 6, 2017 at 10:10 AM, Sven Van Caekenberghe wrote:
>
> > On 6 Jul 2017, at 18:41, Eliot Miranda wrote:
> >
> > Hi Stef,
> >
> >> On Jul 6, 2017, at 1:55 AM, Stepha
> On 6 Jul 2017, at 18:41, Eliot Miranda wrote:
>
> Hi Stef,
>
>> On Jul 6, 2017, at 1:55 AM, Stephane Ducasse wrote:
>>
>> We would like to share this list with you and get your feedback and inputs.
>> It will be presented and discussed again at ESUG.
>>
>> Stef on the behalf of the enginee
+42
> On 6 Jul 2017, at 10:58, Tudor Girba wrote:
>
> +100
>
> Doru
>
>
>> On Jul 6, 2017, at 10:57 AM, Stephane Ducasse
>> wrote:
>>
>> Hi pharoing people
>>
>> Just a little word to tell you that I'm super happy about the future of
>> Pharo.
>> The consortium is growing and will probab
> On 30 Jun 2017, at 09:56, Alistair Grant wrote:
>
> Rajula, thanks for your write-up.
>
> As the person who pushed Rajula to send his email I feel I should
> respond.
>
> While I'm in favour of Rajula's proposed changes, scripting in
> particular will be much easier, I think we need to make
> On 27 Jun 2017, at 14:56, Sven Van Caekenberghe wrote:
>
> P3 is a modern, lean and mean PostgreSQL client for Pharo.
>
> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003]
> and later), implementing the simple query cycle. It supports plaintext a
> On 28 Jun 2017, at 12:14, Norbert Hartl wrote:
>
>>
>> Am 28.06.2017 um 10:42 schrieb Sven Van Caekenberghe :
>>
>>
>>> On 28 Jun 2017, at 10:07, Norbert Hartl wrote:
>>>
>>> Great! I assume it is a smalltalk only client?
>
NoSQL DB's do, like key-value storage, JSON, XML, documents, .. often just
as fast. Being a bit more traditional, cautious at the DB level is considered
good in many circles.
> Norbert
>
>
>> Am 27.06.2017 um 14:56 schrieb Sven Van Caekenberghe :
>>
>> P3
> On 27 Jun 2017, at 17:37, Michael Forster wrote:
>
> On Tue, Jun 27, 2017 at 7:56 AM, Sven Van Caekenberghe wrote:
>> P3 is a modern, lean and mean PostgreSQL client for Pharo.
>>
>> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003]
>
P3 is a modern, lean and mean PostgreSQL client for Pharo.
P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and
later), implementing the simple query cycle. It supports plaintext and md5
password authentication as well as SSL connections. When SQL queries return row
da
Hi Alistair,
I think it is great that you are working on FileSystem and are trying to
contribute. I appreciate your effort to find consensus.
But, and please take this as positive criticism, I feel a bit uneasy when I
read your reasoning, but maybe I am wrong.
You see, the way I understand Fil
> On 22 Jun 2017, at 17:39, Raffaello Giulietti
> wrote:
>
> Hi,
>
> the current (Pharo 6) code reads
>
> ^(self integerAt: byteOffset size: 1 signed: false) == true
>
> so it always returns false, as no integer is identical to true.
>
>
> Instead, it should read
>
> ^(self integerAt: byt
> On 20 Jun 2017, at 09:52, Norbert Hartl wrote:
>
> ??? The only thing that fits us is "plagued by poor docs"!!!
>
> Norbert
Bah, as a language/IDE with ubiquitous access to all source code, we don't even
have a documentation problem ;-)
>> Am 19.06.2017 um 20:05 schrieb Eliot Miranda :
>>
Why would $HOME not be set ?
And if it is not set / seems like a reasonable default.
> On 9 Jun 2017, at 06:06, Holger Freyther wrote:
>
>
>> On 9. Jun 2017, at 11:09, Holger Freyther wrote:
>>
>>
>
>
>> a.) Behave like unix and resolve $HOME to ''
>>
>> $ unset HOME
>> $ echo $HOME/.con
Primitives is a class variable of DiskStore, it contains an instance of
FilePluginPrims.
> On 7 Jun 2017, at 11:30, Rajula Vineet wrote:
>
> Hi,
>
> I have been looking at the DiskStore class and I came across the method
> defaultWorkingDirectory.
>
> defaultWorkingDirectory
> | pathStr
This has been reported before I believe, but there is something weird when
saving images on the command line.
On macOS 10.12.5
$ curl get.pharo.org/60+vm | bash
...
$ ./pharo Pharo.image printVersion
[version] 6.0 #60499
$ ./pharo Pharo.image save one
$ ./pharo one.image printVersion
[version
> On 6 Jun 2017, at 18:18, Ben Coman wrote:
>
>
>
> On Tue, Jun 6, 2017 at 11:11 PM, Esteban Lorenzano
> wrote:
> Dear World,
>
> The time has come for Pharo 6.0!
>
> Woot!
> cheers -ben
Super. Thank you all.
tion to comment.
>> On 2 Jun 2017, at 14:27, Sven Van Caekenberghe wrote:
>>
>> Hi,
>>
>> I am wondering a bit about the state of Pharo 6 64-bit.
>>
>> On one hand the current RC seems to work really well on macOS (for me), it
>> is stable
Hi,
I am wondering a bit about the state of Pharo 6 64-bit.
On one hand the current RC seems to work really well on macOS (for me), it is
stable and clean.
Is the goal to ship this variant as a real finished version ?
If so, I think must make it pass as much unit tests as possible.
I filed
> On 31 May 2017, at 17:46, Peter Uhnak wrote:
>
> The linux distro contains sources twice
> 1) pharo6.0/shared/PharoV60.sources
> 2) pharo6.0/bin/PharoV60.sources
The macOS one-click version also contain PharoV60.source twice, in both:
Contents/MacOS
Contents/Resources
Done:
https://pharo.fogbugz.com/f/cases/20103/Minor-glitch-in-source-code-diff-tool
> On 2 Jun 2017, at 08:11, Stephane Ducasse wrote:
>
> Hi sven
>
> Yes please.
>
> Stef
>
> On Thu, Jun 1, 2017 at 12:10 PM, Sven Van Caekenberghe wrote:
> It seems there i
> On 1 Jun 2017, at 17:20, Sven Van Caekenberghe wrote:
>
>
>> On 1 Jun 2017, at 16:28, Sven Van Caekenberghe wrote:
>>
>> I can confirm that this fixes the problems that I reported. I guess we
>> should include this patch ?
>
> I'll try to
> On 1 Jun 2017, at 16:28, Sven Van Caekenberghe wrote:
>
> I can confirm that this fixes the problems that I reported. I guess we should
> include this patch ?
I'll try to make an issue and patch later tonight
> This fixes some of the failing tests in Kernel-Tests-Nu
> On 1 Jun 2017, at 15:59, Henrik Sperre Johansen
> wrote:
>
> SmallInteger >> digitAt: has an n > 4 ifTrue: [^0] check, in 64bit this needs
> to check against 8.
> (The value represents max number of 8-bit digits in a SmallInteger)
I guess that the special case in there should also be adapte
> On 1 Jun 2017, at 15:59, Henrik Sperre Johansen
> wrote:
>
> SmallInteger >> digitAt: has an n > 4 ifTrue: [^0] check, in 64bit this needs
> to check against 8.
> (The value represents max number of 8-bit digits in a SmallInteger)
I can confirm that this fixes the problems that I reported.
oats, like 1e1231231231.
I understand about this being an implementation detail, but if the choice of
implementation changes the range, it seems important to be able to know this,
one way or another.
> For the rest of the report, it's a bug we will have to track catch and fix
> ASAP
I am working in Pharo 6 RC, 64-bit on macOS 10.12.5
One of the tests of STON fails, #testFloat and I got confused about Floats on
64-bit Pharo 6.
Is there a write-up that explains the new/changed situation ?
Because, what I see is the following:
Float pi.
1.3.
Both the above give me SmallFloa
:34, Esteban Lorenzano wrote:
>
>
>> On 31 May 2017, at 16:32, Sven Van Caekenberghe wrote:
>>
>>
>>> On 31 May 2017, at 16:18, Esteban Lorenzano wrote:
>>>
>>> Hello,
>>>
>>> we are getting ready for release.
>
> On 31 May 2017, at 16:18, Esteban Lorenzano wrote:
>
> Hello,
>
> we are getting ready for release.
> please take a minute to review:
>
> http://pharo.org/STAGE.download
>
> (notice that zerconf download will not work because it is not yet moved… so
> #stable will download current stable
> On 28 May 2017, at 10:39, Ben Coman wrote:
>
> On Sat, May 27, 2017 at 5:41 PM, K K Subbu wrote:
>> On Saturday 27 May 2017 01:41 PM, Ben Coman wrote:
>>>
>>> A question arose in Discord regarding #basicNew, to which I felt like
>>> the proper answer should be
>>> that #basicNew is used only
> On 15 Mar 2017, at 23:25, Sven Van Caekenberghe wrote:
>
>>
>> On 15 Mar 2017, at 20:52, Rein, Patrick wrote:
>>
>> Unfortunately, as I am trying to fix a Travis build, I can not change the
>> call to Zinc.
>>
>> To be clear about this: I
Why can't instance variables/slots not be Symbols as well ...
> On 22 May 2017, at 13:27, Gabriel Cotelli wrote:
>
> If we can get rid off the myriad of class creation methods count me in. :)
>
> I would do something like:
>
> ClassBuilder new
> name: #A;
> superclass: Object;
> addInst
> On 15 May 2017, at 18:03, Denis Kudriashov wrote:
>
>
> 2017-05-15 16:55 GMT+02:00 K K Subbu :
> What exactly are you trying to do? If you want the list of entries in ~
> directory, you could use FileDirectory methods:
>
> (FileDirectory on: (OSProcess thisOSProcess environmentAt: 'HOME'))
t; always default to the default value because DynamicVariable uses the default
> when the variable has a nil value. Not sure what the best solution is there...
>
> Max
>
>
>> On 11 May 2017, at 14:06, Sven Van Caekenberghe wrote:
>>
>> ZnZincServerAdaptor an
> Cheers,
> Max
>
>
>> On 11 May 2017, at 13:05, Max Leske wrote:
>>
>>>
>>> On 11 May 2017, at 11:49, Sven Van Caekenberghe wrote:
>>>
>>> Hi Max,
>>>
>>> First thank you for the feedback, the discussion so far
: One resource limit not yet moved under the new scheme is the maximum line
length (currently set to 4096).
> On 6 May 2017, at 15:30, Max Leske wrote:
>
>>
>> On 5 May 2017, at 17:11, Sven Van Caekenberghe wrote:
>>
>> Max,
>>
>>> On 5 May
> On 9 May 2017, at 16:10, Esteban Lorenzano wrote:
>
> http://pharo.org/STAGE.gnu-linux-installation
>
> I don’t think they will work.
> We need to update or remove.
>
> Esteban
It is impossible to support all the Linux distros out there, they are a PIA if
you ask may. There are regularly p
Max,
> On 5 May 2017, at 16:59, Max Leske wrote:
>
> Hi,
>
> I'm performing a legal request that has more than 4000 parameters. This
> causes the Zinc server to return 400: Bad Request because
> ZnMultiValueDictionary is limited to 256 entries by default.
>
> The dictionary has the option to
I have a feeling that you are working on the wrong level, consider:
file := FileReference newTempFilePrefix: 'data' suffix: '.txt'.
file writeStreamDo: [ :out | out << 'Casimiro de Almeida Barreto' ].
file contents.
file ensureDelete.
file exists.
The #newTempFilePrefix:suffix: method uses 'FileL
rs having
trouble using FileSystem on Windows.
> On Sun, Apr 30, 2017 at 6:54 PM, Casimiro de Almeida Barreto
> wrote:
> Hello,
>
> -Mensagem original-
> De: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] Em nome de Sven Van
> Caekenberghe
> Enviada
> On 30 Apr 2017, at 09:48, Max Leske wrote:
>
> Hi Casimiro,
>
> have you tried using normal slashes in the path name? FileSystem should
> convert those to system path delimiters automatically. So:
>
> C:/temp/e8720bb4-b90a-0d00-9b1f-008709e5552b.txt
>
> And possibly you'll need a leading s
> On 27 Apr 2017, at 17:49, Torsten Bergmann wrote:
>
> Hi,
>
> our community today hit the 2 issues mark in FogBugz.
>
> https://pharo.fogbugz.com/f/cases/2
>
> And a good change to once again say THANK YOU, especially to the ones who
> care most on
>
> - updating the bug tracke
I like it !
> On 24 Apr 2017, at 08:58, Pavel Krivanek wrote:
>
> Hi,
>
> I tried to prepare some "geeky" screenshot for Pharo 6 announcements and
> advertisements.
>
> https://goo.gl/photos/NF5EC6dCinXRWosA9
>
> -- Pavel
There are already #pairsDo: and #pairsCollect: that could be used:
#(a b c d e f g h) pairsCollect: [ :x :y | y ]
=> #(#b #d #f #h)
> On 19 Apr 2017, at 22:12, Tudor Girba wrote:
>
> I like this one.
>
> Doru
>
>
>> On Apr 19, 2017, at 8:43 PM, Stephane Ducasse
>> wrote:
>>
>> Hi
>>
>
> On 15 Apr 2017, at 13:41, Stephan Eggermont wrote:
>
> On 14/04/17 09:09, Esteban Lorenzano wrote:
>> I wanted to let you know that we talked at the board and we want to make the
>> DarkTheme a default for Pharo 6.0.
>> This is just because we want to have a visual immediate reference of
>>
It is all a question of definition, I guess.
(STON fromString: '2e2') = (STON fromString: '2E+2'). => true
(STONJSON fromString: '2e2') = (STONJSON fromString: '2E+2'). => true
(NeoNumberParser parse: '2e2') = (NeoNumberParser parse: '2E+2'). => true
I believe the 'old school' Smalltalk syntax
>
> -- Pavel
>
> 2017-03-28 8:07 GMT+02:00 Sven Van Caekenberghe :
> So it seems that
> ZnCharacterEncoderTests>>#testByteEncoderFromUrl started failing on the CI
> infrastructure but it passes fine for normal users and used to behave well in
> the past.
>
> It get
So it seems that
ZnCharacterEncoderTests>>#testByteEncoderFromUrl started failing on the CI
infrastructure but it passes fine for normal users and used to behave well in
the past.
It gets a file from the internet and does some stuff with it, very simple.
Any ideas ?
Sven
> On 25 Mar 2017, at 00:37, Ben Coman wrote:
>
> On Sat, Mar 25, 2017 at 2:04 AM, Sven Van Caekenberghe wrote:
>>
>> Some further notes.
>>
>>> On 24 Mar 2017, at 14:20, Sven Van Caekenberghe wrote:
>>>
>>> Hmm, we'll have to stu
Some further notes.
> On 24 Mar 2017, at 14:20, Sven Van Caekenberghe wrote:
>
> Hmm, we'll have to study this better, since the following still works for me
> (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails
> for me):
>
> ZnEasy
Hmm, we'll have to study this better, since the following still works for me
(while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails
for me):
ZnEasy getPng: 'http://pharo.org/files/pharo.png'.
This is also the URL used in the unit tests.
Now, needless to say that the day
alf of Ben Coman
>
> Sent: Wednesday, March 15, 2017 19:16
> To: Pharo Development List
> Subject: Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource
>
> On Thu, Mar 16, 2017 at 1:25 AM, Sven Van Caekenberghe wrote:
>>
>> Hi,
>>
>> This is a
> On 15 Mar 2017, at 18:28, Rein, Patrick wrote:
>
> Thanks for looking into this :)
>
> @Dave: Can you explain what you would have expected to happen here? I see the
> point
> that squeaksource could also encode the response as UTF-8. However, currently
> the
> page is correctly encoded and
> On 15 Mar 2017, at 19:16, Ben Coman wrote:
>
> On Thu, Mar 16, 2017 at 1:25 AM, Sven Van Caekenberghe wrote:
>>
>> Hi,
>>
>> This is a recurring issue.
>
>
> It would be cool if some magic(TM) could raise a dialog with an
> explanation and pul
Hi,
This is a recurring issue. The problem is that the server serves a resource, in
this case text/html, without specifying its encoding. Today, when no encoding
is specified, we default to UTF-8. In this case the server silently serves a
resource which is ISO-8895-1 encoded.
The error is trig
I understand, Torten, but we wil get there, one day.
> On 9 Mar 2017, at 23:04, Torsten Bergmann wrote:
>
> Uko wrote:
>> If there is a rule not to duplicate preferences, why is catalog not
>> following it?
>
> Because at the time when I implemented it for catalog there was no other
> setting
No it is not a Spotter bug, Spotter uses multi threading very well. So well you
did not see it ;-)
UI Monticello actions do indeed block the main UI thread, like almost all other
tool actions. That is not necessarily bad, you want to wait for them.
Monticello HTTP operations do have proper time
Guys,
Please stop speculating, no it is not Monticello, no it is not HTTP access, no
it is not networking itself, it is DNS resolution, in a very specific situation:
https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName-sometimes-hangs-when-there-is-no-network
Note also t
Thank you, Andrei, for your continued efforts !
> On 7 Mar 2017, at 14:47, denker wrote:
>
>
>> Log Message:
>> ---
>> 60436
>> Moose
>>
>> http://files.pharo.org/image/60/60436.zip
>>
>
>
> This brings changes to the inspector, debugger and fast table renderer for
> glamour.
> Det
> On 7 Mar 2017, at 11:04, Pavel Krivanek wrote:
>
> Hi,
>
> because SublimishTheme was removed from Pharo 6 you need to load it manually
> if you like it. You can simply find it in the Catalog or load it here:
>
> Metacello new
> baseline: 'SublimishTheme';
> repository: 'github://pavel-
configuration: #SublimishTheme;
> version: '1.0.0';
> load
>
> 2017-03-07 10:06 GMT+01:00 Sven Van Caekenberghe :
>
> > On 7 Mar 2017, at 09:51, GitHub wrote:
> >
> > Log Message:
> > ---
> > 60434
> > 19801 Remove Subl
> On 7 Mar 2017, at 09:51, GitHub wrote:
>
> Log Message:
> ---
> 60434
> 19801 Remove SublimishTheme
> https://pharo.fogbugz.com/f/cases/19801
So where/how can this theme be loaded again, I really, really liked it.
I know, it is just a conflict in goals/objectives/target audience.
I think we can only solve that with 2 versions, an edu and a pro version, that
maybe should only differ in a couple of preferences and defaults.
> On 6 Mar 2017, at 22:55, Yuriy Tymchuk wrote:
>
> The problem is that there are
> On 6 Mar 2017, at 19:51, stepharong wrote:
>
> We should make it available from the catalog :)
Yes, it most certainly should be.
If only we could then tell user to type
Shift-Enter Sublimish Enter
to install it using Spotter right from the catalog ;-)
Sorry, I couldn't resist ...
> 20
Ben,
Nice work !
So the conclusion is that only #addressForName:[timeout:] is used a lot and its
counterpart #nameForAddress:[timeout:] just a little bit. Right ?
What was your goal in doing this analysis ?
Sven
> On 27 Feb 2017, at 15:40, Ben Coman wrote:
>
> Following up discussion on the
> On 24 Feb 2017, at 18:56, Sven Van Caekenberghe wrote:
>
>>
>> On 24 Feb 2017, at 18:14, Ben Coman wrote:
>>
>>
>>
>> On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe wrote:
>>
>>> On 20 Feb 2017, at 10:30, Pavel Kriva
> On 24 Feb 2017, at 18:14, Ben Coman wrote:
>
>
>
> On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe wrote:
>
> > On 20 Feb 2017, at 10:30, Pavel Krivanek wrote:
> >
> >
> >
> > 2017-02-20 10:27 GMT+01:00 Guillermo Polito :
&g
b 20, 2017 at 5:25 PM, Sven Van Caekenberghe wrote:
>
>> On 20 Feb 2017, at 16:45, GitHub wrote:
>>
>> 19728 Integrate Sublimish theme
>> https://pharo.fogbugz.com/f/cases/19728
>
> Very nice !
>
> But does it also not need Spotter styling ? This looks odd:
>
>
>
> On 20 Feb 2017, at 10:30, Pavel Krivanek wrote:
>
>
>
> 2017-02-20 10:27 GMT+01:00 Guillermo Polito :
> As far as I remember, the main problem was not bandwidth but a blocking and
> non-responsive UI.
> Imagine I'm in the university, or in a company with a proxy. And I forget to
> set the
I understand completely, I agree and strongly vote for A as well.
> On 19 Feb 2017, at 21:05, Torsten Bergmann wrote:
>
> In the past in Pharo it was possible to open Spotter, type in the name of a
> framework/project to load
> from catalog, perform a search and just hit ENTER to easily instal
#x27;"
Or even:
'https://pharo.org' asUrl. "(ZnUrl fromString: 'https://pharo.org')"
Though it is an option. (This goes for all similar objects, like date, time,
..).
Then it does become a discussion about what a print string should be.
> On 19 Feb 2017, at
Ah, you're right: there is a difference between printing a textual
representation on a stream / window and doing the same with the actual
(print)string. I was not yet fully awake I guess.
> On 19 Feb 2017, at 10:59, Tudor Girba wrote:
>
> Hi,
>
> Hmm, I think I do not see it :).
>
> Let’s t
Stef is right, there is something strange. Consider the following 4
expressions, each time with the result of 'Print It' inserted:
#foo->'foo'. "#foo->'foo'"
(#foo->'foo') printString. "'#foo->''foo'''"
'foo'. "'foo'"
'foo' printString. "'''foo'''"
In a Workspace (not Playground), the following
the latest pharo VMs.
>
> In any case, this problem does not require any image-side changes. It will be
> in Pharo 6 if the Pharo 6 release VM features the new compactor.
>
> Best,
>
> Clement
>
> On Thu, Feb 16, 2017 at 4:26 PM, denker wrote:
>
> >
big deal, today.
But still, we have to fix this discrepancy between 28 and 47.
Is the 'release cleanup' done on this image each time ?
> Marcus
>
>> On 16 Feb 2017, at 16:07, Sven Van Caekenberghe wrote:
>>
>> What Ben says that he thinks it might already be
What Ben says that he thinks it might already be solved.
Maybe not on all platforms.
> On 16 Feb 2017, at 15:59, denker wrote:
>
> Yes, this has to be solved on the VM level and will be read when it is ready.
> The release should bot be hold up due to this, therefore I removed the
> milestone.
> On 16 Feb 2017, at 14:32, Denis Kudriashov wrote:
>
>
> 2017-02-16 14:26 GMT+01:00 Sven Van Caekenberghe :
> But we could integrate the patch (his work marking slow tests) and the code,
> and then disable the enforcing mechanism. That will allow us to re-able it
> quic
But we could integrate the patch (his work marking slow tests) and the code,
and then disable the enforcing mechanism. That will allow us to re-able it
quickly later on.
> On 16 Feb 2017, at 14:23, Esteban Lorenzano wrote:
>
>
>> On 16 Feb 2017, at 13:49, Guillermo Polito wrote:
>>
>> I vot
Note that he managed to run the System Report UI, which means his image was
running pretty normally at some point ...
> On 12 Feb 2017, at 10:26, Ben Coman wrote:
>
> On Sun, Feb 12, 2017 at 5:18 AM, Andriy Tykhonov wrote:
>> Ben Coman writes:
>>
>>> Are you on 64-bit using 32-bit Pharo?
>>
> On 11 Feb 2017, at 09:48, GitHub wrote:
>
> Branch: refs/heads/6.0
> Home: https://github.com/pharo-project/pharo-core
> Commit: fcd75f0830aa6925f2fee68011ae20fb30efee81
>
> https://github.com/pharo-project/pharo-core/commit/fcd75f0830aa6925f2fee68011ae20fb30efee81
> Author: Jenkin
22:33, Nicolai Hess wrote:
>
>
>
> 2017-02-04 13:40 GMT+01:00 Sven Van Caekenberghe :
>
> > On 4 Feb 2017, at 13:01, Nicolai Hess wrote:
> >
> >
> >
> > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
> > Hi Nicolai,
> >
> > The FileSyste
ge, i.e. do not follow the sent message, give
back debugger control after the method invoked returns or whenever before that
execution should return inside a block used as an argument.
> On Mon, Feb 6, 2017 at 7:39 PM, Sven Van Caekenberghe wrote:
>
> > On 6 Feb 2017, at 18:55, Hil
> On 6 Feb 2017, at 21:25, Sean P. DeNigris wrote:
>
> How about...
>
> Into
>
> Step into the highlighted message, i.e. dive the debugger into the method
> which handles it
>
> Over
>
> Step over the highlighted message, i.e. execute it, but keep the debugger
> focused on the current method
> On 6 Feb 2017, at 23:01, werner kassens wrote:
>
> On 02/06/2017 09:00 PM, Sven Van Caekenberghe wrote:
>> Regarding the poor seed at startup:
>>> 1k outside runs of 'NeoUUIDGenerator new nextRandom16' (on a fresh image)
>>> gives me only 116 uniqu
> On 6 Feb 2017, at 22:59, Peter Uhnak wrote:
>
>
>>> On Windows (10) (with latest 6 image and VM) `Time microsecondClockValue`
>>> returns microseconds, but (presumably the system) cannot give precision
>>> beyond 1 second - this will imho need a VM fix;
>>
>> I find that quite hard to beli
> On 6 Feb 2017, at 22:33, Nicolai Hess wrote:
>
>
>
> 2017-02-04 13:40 GMT+01:00 Sven Van Caekenberghe :
>
> > On 4 Feb 2017, at 13:01, Nicolai Hess wrote:
> >
> >
> >
> > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
> > Hi Nic
_identifier
>>
>> <<
>> When generated according to the standard methods, UUIDs are for practical
>> purposes unique, without depending for their uniqueness on a central
>> registration authority or coordination between the parties generating them,
>&
> On 6 Feb 2017, at 18:55, Hilaire wrote:
>
> How will you describe these buttons in the debugger?
> Here are proposals for tooltips, please fix it, I am sure there are
> better way to write it.
>
> Proceed
> Quit the debugger and resume the execution of the method.
>
> Restart
> Reset the loc
next: 8 ].
to get random bytes.
> Uko
>
>
>> On 6 Feb 2017, at 14:35, Sven Van Caekenberghe wrote:
>>
>>
>>> On 6 Feb 2017, at 14:17, Yuriy Tymchuk wrote:
>>>
>>> Hi everyone,
>>>
>>> I’m using the session id (Smallt
enerating them,
unlike most other numbering schemes. While the probability that a UUID will be
duplicated is not zero, it is so close to zero as to be negligible.
>>
Read the last sentence.
So IMO it is certainly not 'broken'.
Note also that NeoUUID uses different ele
> On 6 Feb 2017, at 14:17, Yuriy Tymchuk wrote:
>
> Hi everyone,
>
> I’m using the session id (Smalltalk session id) for my data recording, so I
> can distinguish if the recorded events came from the same session. The idea
> is that each time an image is started a new session is created and a
n and it would be spinning. So
> when you run a task you can easily see that the task is still running
>
> Uko
>
>> On 5 Feb 2017, at 20:01, Sven Van Caekenberghe wrote:
>>
>> A bit off topic, but I would do the STON writing as follows:
>>
>> [
>&g
A bit off topic, but I would do the STON writing as follows:
[
(FileLocator temp / 'file.ston') writeStreamDo: [ :out |
(STON writer on: out) in: [ :stonWriter |
30 timesRepeat: [
stonWriter nextPut: Smalltalk allClasses ] ] ].
] timeToRun. "0:00:00:02.176"
But in light of alternativ
> On 4 Feb 2017, at 21:14, stepharong wrote:
>
> I will talk about guille about his file implementation and we can see what we
> can do.
Yes, that is step 1, here is the issue I was talking about:
https://pharo.fogbugz.com/f/cases/18414/Change-usages-of-StandardFileStream-and-MultiByteFileSt
> On 4 Feb 2017, at 19:09, stepharong wrote:
>
>
>>> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
>>> Hi Nicolai,
>>>
>>> The FileSystem API is a bit inconsistent, yes.
>>>
>>> This is how you can use it:
>>>
&g
> On 4 Feb 2017, at 16:24, Sean P. DeNigris wrote:
>
> kilon.alios wrote
>> Time to make sure they work as expected.
>
> And tag them #'Pharo6.0' once it's released. In the process of loading
> ChronosManager from the Catalog in Pharo 5, I got a warning that it was not
> marked as safe (sorry I
> On 4 Feb 2017, at 13:01, Nicolai Hess wrote:
>
>
>
> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
> Hi Nicolai,
>
> The FileSystem API is a bit inconsistent, yes.
>
> This is how you can use it:
>
> (FileLocator temp / 'foo.txt
Hi Nicolai,
The FileSystem API is a bit inconsistent, yes.
This is how you can use it:
(FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
out binary.
(ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].
(FileLocator temp / 'foo.txt') readStreamDo: [ :in |
in binary.
ZnCha
601 - 700 of 2686 matches
Mail list logo
