On 13 Mar 2014, at 03:12, Sebastian Sastre sebast...@flowingconcept.com wrote:
On Mar 12, 2014, at 7:15 PM, Max Leske maxle...@gmail.com wrote:
To answer my own question (RTFM…):
This is a credit card processing library. I needed this for airflowing an
application from flowing.”
Thanks Sebastien
I’ll let your know if we use it. And Sven’s right: beautiful!
Max
On 13.03.2014, at 03:12, Sebastian Sastre sebast...@flowingconcept.com wrote:
On Mar 12, 2014, at 7:15 PM, Max Leske maxle...@gmail.com wrote:
To answer my own question (RTFM…):
This is a credit card
Thanks this is nice to see all these packages getting exposure
On 12 Mar 2014, at 22:01, Sebastian Sastre sebast...@flowingconcept.com wrote:
Hi there,
actually this was announced a long ago, but we moved it to github:
https://github.com/sebastianconcept/Merchant
Also available in Pharo's
Hi guys
I need the following behavior and I started to implement it (but I’m not sure
that I implemented in a good way).
But may be this method already exist.
testDiffs
self run: #testDiffs
self assert: (#(a b c d e f) diff: #(a b z k)) equals: {#(c d e f) .
#(z k)}.
On 13.03.2014, at 08:52, Pharo4Stef pharo4s...@free.fr wrote:
Hi guys
I need the following behavior and I started to implement it (but I’m not sure
that I implemented in a good way).
But may be this method already exist.
testDiffs
self run: #testDiffs
self assert:
On Thu, Mar 13, 2014 at 8:52 AM, Pharo4Stef pharo4s...@free.fr wrote:
#(a b c d e f) diff: #(a b z k)
Use #difference:
#(a b c d e f) difference: #(a b z k). == #(#f #d #e #c)
#(a b z k) difference: #(a b c d e f) == #(#k #z)
--
Damien Cassou
http://damiencassou.seasidehosting.st
Success
Branch: refs/tags/30796
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/3.0
Home: https://github.com/pharo-project/pharo-core
Commit: 9fc2c6dd4f75f31423a9af2c475bad1e13c95ea0
https://github.com/pharo-project/pharo-core/commit/9fc2c6dd4f75f31423a9af2c475bad1e13c95ea0
Author: Jenkins Build Server bo...@pharo-project.org
Date:
I was thinking that I could do it in one pass.
On Thu, Mar 13, 2014 at 8:52 AM, Pharo4Stef pharo4s...@free.fr wrote:
#(a b c d e f) diff: #(a b z k)
Use #difference:
#(a b c d e f) difference: #(a b z k). == #(#f #d #e #c)
#(a b z k) difference: #(a b c d e f) == #(#k #z)
--
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in
its current form...
As others have mentioned, the class pseudo-variable is confusing, but here
are some that I find worse:
- The receiver does not change with the selection. For me, this was a key
feature of the
Sean,
The previous tools had quirks as well, lets try to fix the issues one by one,
can't be that big a problem with your UI/Morph/Spec skills ;-)
I find the Eye tools pretty cool, they do improve certain aspects (like sharing
between inspector/explorer, making it easy to add custom
It would be great if we could reach an effective goal: having a super cool
inspector and avoiding reinventing all this.
GTInspector is truly effective and usable. Maybe we should change the name of
the moose image into Pharo-Dev or something.
Alexandre
On Mar 13, 2014, at 8:51 AM, Sean P.
These are different things:
- Eye tools are a reimplementation of the classic tools
- GTInspector and friends try to break new ground, reinvent ideas and concepts
For me this is not an either-or discussion, both have their place and are
important.
And it is perfectly possible to use a Moose
These are different things:
- Eye tools are a reimplementation of the classic tools
- GTInspector and friends try to break new ground, reinvent ideas and concepts
I do not know whether they are that different.
Nautilus is a reimplementation of the OB and the old standard browser.
Is Nautilus
Hi everyone,
I want to send a thumbs up to everyone working on Pharo, coming from the
Yesplan.be team.
Over the past few months, we have been working on migrating the development of
Yesplan from Pharo1.4 to Pharo3.0 (yes, we did skip Pharo2.0).
I have been working in Pharo3 exclusively since
This is truly great Johan!
Continue all the good work!
Alexandre
On Mar 13, 2014, at 12:42 PM, Johan Brichau jo...@inceptive.be wrote:
Hi everyone,
I want to send a thumbs up to everyone working on Pharo, coming from the
Yesplan.be team.
Over the past few months, we have been working on
Thanks Johan.
On 13 Mar 2014, at 16:42, Johan Brichau jo...@inceptive.be wrote:
Hi everyone,
I want to send a thumbs up to everyone working on Pharo, coming from the
Yesplan.be team.
Over the past few months, we have been working on migrating the development
of Yesplan from Pharo1.4 to
Hi guys,
Do we have a method to lock a file at the OS level? I searched in image but
I cannot find anything. If it would work in gemstone too that would be nice.
Thanks!
--
Mariano
http://marianopeck.wordpress.com
Not aware of a way to do it directly... If you can do it from the shell,
then System classperformOnServer: will be your friend:)
Dale
On Thu, Mar 13, 2014 at 9:14 AM, Mariano Martinez Peck
marianop...@gmail.com wrote:
Hi guys,
Do we have a method to lock a file at the OS level? I searched
Thanks and good holidays
Hi everyone,
I want to send a thumbs up to everyone working on Pharo, coming from the
Yesplan.be team.
Over the past few months, we have been working on migrating the development
of Yesplan from Pharo1.4 to Pharo3.0 (yes, we did skip Pharo2.0).
I have been
On Mar 13, 2014, at 1:14 PM, Mariano Martinez Peck marianop...@gmail.com
wrote:
Hi guys,
Do we have a method to lock a file at the OS level? I searched in image but I
cannot find anything.
We couldn’t have done airflowing without that feature (which enables horizontal
scaling).
Take a
Hi Mariano,
It is supported directly in OSProcess. See the unit test for examples.
Dave
Hi guys,
Do we have a method to lock a file at the OS level? I searched in image
but
I cannot find anything. If it would work in gemstone too that would be
nice.
Thanks!
--
Mariano
Cool.
Do you try it on Amber?
2014-03-11 17:13 GMT+04:00 Gabriel Cotelli g.cote...@gmail.com:
Hi,
I'm announcing the first official release of RenoirSt, a DSL enabling
programmatic cascading style sheet generation for Pharo.
For the impatient, you can load it in your 3.0 image
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the
contents etc.
A general pain. I was clicking on the inspect option to see what the real
content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris
We're getting there! But...
Issue 13074: Renaming a package - Wrong MC Tags
https://pharo.fogbugz.com/default.asp?13074
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/RPackage-not-quite-licked-tp4749038.html
Sent from the Pharo Smalltalk Developers mailing list
yeah, and saw what happens when you use the keyboard?
try this:
1. selecting in a workspace
2. cmd+shift+i
3. when it opens, press 3 ro 4 times the right arrow
you navigate the class instead of the instace
not great
I miss the old explorer
On Mar 13, 2014, at 4:30 PM, Sven Van
Hi Mariano,
It is supported directly in OSProcess. See the unit test for examples.
Dave
Sorry, I should have been more clear about this. The classes in the
OSProcess package are OSFileLock and OSFileRegionLock, as well as the
methods in category 'file locking' of class UnixOSProcessAccessor.
I would like to have a basic mode without class and all instvars because they
get in my way.
Stef
I went back to compare the explorer in 2.0, the only visible (not behaviour)
difference that I see is the class field, it would probably be better to lose
that:
Screen Shot 2014-03-13 at
But you have GB's of RAM, right ;-)
See EyeInspector#limit1 and limit2 that control how much to show in
collections, maybe 10 it too high ;-)
But in general, I think maybe we could use a dedicated EyeStringInspector.
I agree that viewing a bigger string in the explorer/tree view is a bit
Good ideas.
Not silly if what you do is creating a gateway that gets stuff back from a
REST api and you need to figure out some parts of what you get back (and
one things is a huge Base64-encoded file - open that in the
EyeTreeExplorer.)
Now, on the GB thing, sure but the EyeTreeExplorer
On 13 Mar 2014, at 22:46, Sven Van Caekenberghe s...@stfx.eu wrote:
Maybe #childrenFor[Object]: can be used to shortcut the depth of the tree.
For strings characters could then no longer be shown.
Well, this does the trick, but it is getting uglier:
EyeTreeInspector#childrenForObject:
On Mar 13, 2014, at 6:53 PM, p...@highoctane.be wrote:
Not silly if what you do is creating a gateway that gets stuff back from a
REST api and you need to figure out some parts of what you get back (and one
things is a huge Base64-encoded file
that actually happened to me a couple of times,
Where is the old motto, 'Just doit' ?
With this simple change the class field is gone from the explorer:
EyeTreeInspector#childrenForObject: anObject
self flag: 'Minor Ugliness to filter out the self and instavr node'.
^ anObject inspector elements
reject: [
Looks like there is some shared fun with ZnClient and https then :-)
... on my way to ZnNinja (slowly).
Sven, HTTPComponents is really Ubercool!
Phil
On Thu, Mar 13, 2014 at 11:00 PM, Sebastian Sastre
sebast...@flowingconcept.com wrote:
On Mar 13, 2014, at 6:53 PM, p...@highoctane.be wrote:
damn!
I will check it tomorrow :)
Esteban
On 13 Mar 2014, at 20:40, Sean P. DeNigris s...@clipperadams.com wrote:
We're getting there! But...
Issue 13074: Renaming a package - Wrong MC Tags
https://pharo.fogbugz.com/default.asp?13074
-
Cheers,
Sean
--
View this message in
Thanks :)
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/RPackage-not-quite-licked-tp4749038p4749075.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
36 matches
Mail list logo
