2015-06-15 10:07 GMT+02:00 Ben Coman b...@openinworld.com:
whoops. please excuse my previous clicktoofast.
On Mon, Jun 15, 2015 at 3:51 PM, Clément Bera bera.clem...@gmail.com
wrote:
Hey all,
Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but
that was definitely
whoops. please excuse my previous clicktoofast.
On Mon, Jun 15, 2015 at 3:51 PM, Clément Bera bera.clem...@gmail.com wrote:
Hey all,
Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but
that was definitely what I was trying to experiment with.
As Thierry mentioned, these
Well, we already have in-image a #once like solution based on memoization.
block := [ :key | key factorial ] memoized.
first time
[1000 to: 1500 do: [:index |block value: index]] timeToRun.
0:00:00:01.598
second time, cached
[1000 to: 1500 do: [:index |block value: index]] timeToRun.
btw, Are meta links planned to show up as highlighting in code views?
Yes, we will soon have the new editor everywhere which allows to do this.
The most important is to visualize breakpoints. I want to have dedicated visuals
for that.
Then, later, I want to show meta links in general, but
Hey all,
Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but
that was definitely what I was trying to experiment with.
As Thierry mentioned, these elements come from C/C++ where you have macros
that are very useful when writing high performance code so your code can be
both
On Mon, Jun 15, 2015 at 3:51 PM, Clément Bera bera.clem...@gmail.com wrote:
Hey all,
Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but
that was definitely what I was trying to experiment with.
As Thierry mentioned, these elements come from C/C++ where you have macros
Le 14/06/2015 18:39, Holger Freyther a écrit :
On 13 Jun 2015, at 14:39, Clément Bera bera.clem...@gmail.com wrote:
Dear Clement,
This is an interesting problem. There is currently no simple way of executing a
message at compile-time instead of at runtime in Pharo, which is useful to
On 13 Jun 2015, at 14:39, Clément Bera bera.clem...@gmail.com wrote:
Dear Clement,
This is an interesting problem. There is currently no simple way of executing
a message at compile-time instead of at runtime in Pharo, which is useful to
have settings but no runtime overhead.
I did a
On Mon, Jun 15, 2015 at 2:34 AM, Thierry Goubier
thierry.goub...@gmail.com wrote:
Le 14/06/2015 18:39, Holger Freyther a écrit :
On 13 Jun 2015, at 14:39, Clément Bera bera.clem...@gmail.com wrote:
Dear Clement,
This is an interesting problem. There is currently no simple way of
Hi Ben,
Le 15/06/2015 01:09, Ben Coman a écrit :
On Mon, Jun 15, 2015 at 2:34 AM, Thierry Goubier
thierry.goub...@gmail.com wrote:
Le 14/06/2015 18:39, Holger Freyther a écrit :
On 13 Jun 2015, at 14:39, Clément Bera bera.clem...@gmail.com wrote:
Dear Clement,
This is an interesting
This is an interesting problem. There is currently no simple way of
executing a message at compile-time instead of at runtime in Pharo, which
is useful to have settings but no runtime overhead.
I did a simple extension for opal compiler for this purpose, adding the
message Cvalue, which is
Le 13/06/2015 14:39, Clément Bera a écrit :
This is an interesting problem. There is currently no simple way of
executing a message at compile-time instead of at runtime in Pharo,
which is useful to have settings but no runtime overhead.
This is the discussion I wanted to have about pragmas...
Hi Torsten, Hi Ben,
On Jun 12, 2015, at 2:49 PM, Torsten Bergmann asta...@gmx.de wrote:
Hi,
for tracing and logging one could easily write:
foo
...
Log enabled ifTrue: [ do some tracing here ].
...
but this always requires some message sends/checks if the debug mode is
active.
I know we usually have the debugger in front of us - but sometimes a trace or
log is
required to see where code crashes. Think of a headless situation in a
webserver or
a small device like the pi where you want to reduce the performance overhead.
This leads to several questions:
- Is
This leads to several questions:
- Is something like this feasible/already possible in Pharo?
- Any pointers on how Opal does optimizations? Do we have similar
optimizations (removing
code that could not be reached) that could be used.
- How do you usually deal with additional tracing
Hi,
for tracing and logging one could easily write:
foo
...
Log enabled ifTrue: [ do some tracing here ].
...
but this always requires some message sends/checks if the debug mode is active.
This is OK while debugging/tracing to find errors - but for runtime one whishes
to have the
best
On Sat, Jun 13, 2015 at 5:49 AM, Torsten Bergmann asta...@gmx.de wrote:
Hi,
for tracing and logging one could easily write:
foo
...
Log enabled ifTrue: [ do some tracing here ].
...
but this always requires some message sends/checks if the debug mode is
active.
This is OK while
Hi Torsten,
On Jun 12, 2015, at 2:49 PM, Torsten Bergmann asta...@gmx.de wrote:
Hi,
for tracing and logging one could easily write:
foo
...
Log enabled ifTrue: [ do some tracing here ].
...
but this always requires some message sends/checks if the debug mode is
active.
This
18 matches
Mail list logo
