Hi All,
I am not able to start my stone as I inadvertantly deleted the ..LCK file. :)
Is there a way to fix this?
Thanks,
Hello!
In Pharo 7.0.4,
Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ]
>>> #($1 $0 $1 $0 10 '10')
Bug or feature?
Herby
On 10 September 2019 at 00.56.28, Richard O'Keefe (rao...@gmail.com) wrote:
Does that sound like a way forward?
I could convert my implementation of this interface to
Pharo if people would like me to.
Hi Richard,
It seems like what you propose (in sofar as I understand it) is already
present in
Hi,
I really think we should have an efficient way to chain operations on
collections and alike. In my personal opinion, this should be backed by
transducers, as they decouple the operations from the type the data source
and sink. Hence they are applicable to different collection types, streams
a
Herby,
It's a feature. ;-)
<< sends putOn: message to the non-collection args.
Integer>>#putOn: aStream
aStream isBinary
ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each
] ]
ifFalse: [ self asString putOn: aStream ]
String>>#putOn: aStream
I think it's fair to say that #<< *is* a bug.
There does not seem to be any coherent description of what it means.
It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
something else, in some confusing ways.
CommandLineHandler #nextPutAll: (sent somewhere else)
Integer
Development happens in Pharo 8 first, with possible back ports if really
necessary.
The last relevant change was the following:
https://github.com/pharo-project/pharo/pull/2698
> On 10 Sep 2019, at 14:54, Richard O'Keefe wrote:
>
> I think it's fair to say that #<< *is* a bug.
> There does no
The lock file is tested to see if the stone is running and if you delete it
then the system should be willing to start a new stone. Please reboot your
machine, try the ’startstone’ command again, and then post the output of to the
gemstone mailing list.
> On Sep 10, 2019, at 2:24 AM, ian wrote
On 10. 9. 2019 14:54, Richard O'Keefe wrote:
I think it's fair to say that #<< *is* a bug.
There does not seem to be any coherent description of what it means.
It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
something else, in some confusing ways.
CommandLineHandler #n
On 10. 9. 2019 15:20, Sven Van Caekenberghe wrote:
Development happens in Pharo 8 first, with possible back ports if really
necessary.
The last relevant change was the following:
https://github.com/pharo-project/pharo/pull/2698
That's a very nice change, indeed. Thank you.
But there's still
Dear all,
I'm struggling with passing an ExternalAddress to a c function call with
uFFI. Firstly, I get the ExternalAddress from this method:
myFFI>>create: aString
^ self
ffiCall: #(void * CreateObject (String aString) )
[in c:
void* CreateObject(char* szProgId)]
The method that
It is good that you have a coherent idea of how << can work.
The question I was addressing is how << *DOES* work in Pharo.
Having simple things working, if they are kept consistent,
is indeed good. The problem is that in Pharo 7 they are NOT
consistent, and << does NOT work consistently, because t
12 matches
Mail list logo
