Which honestly, unless youre in a technical space like physics finance or
biotech - or a high end database - the perception of speed is going to be
driven almost entirely by the ui.
People need feedback loops.
On Wed, Apr 23, 2014 at 5:13 PM, Lundberg, Johannes <
johan...@brilliantservice.co.jp
+1
I use dispatch with blocks all the time in my iOS apps. It's a great, easy
to use API if you wanna offload stuff off the main thread, or just delay
execution. For example to keep the UI smooth and responsive.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信した
Yes you can use callbacks and delegates.
Blocks are much more elegant - they will handle the context and alloc and
derefrencing and a lot of just ugly moving of data.
A block wrapped API is amazing - you need to define a block one time per
function - not per call like a callback - and you're
You'd be surprised where you can apply a dispatch - anywhere there is an
iterator, a thread forked, or a read from/to file, network, or io you can
- for almost no cost - just wrap that call in a block (my brain wants to
call it an nsoperation queue ) and dispatch it.
Basically anything you don't
В Wed, 23 Apr 2014 08:58:24 +0200
Baptiste Daroussin пишет:
>
> Thank you for those patches, imho that is something we really do
> need.
> I would just have a couple of side notes:
> Wouldn't it be possible to use callbacks in the dispatch call rather
> than blocks?
If I understand you correctl
В Tue, 22 Apr 2014 18:34:16 -0700
Neil Schroeder пишет:
> Have you tried applying these changes to 1.15?
Unfortunately not yet - it's only the beginning
The current number-one task - it to get current working port for Stable
10 branches ...
Task number two - to learn the extent necessary for
В Tue, 22 Apr 2014 19:25:54 -0700
"Eric L. Camachat" пишет:
> > 1. show me, please, /etc/make.conf
> > 2. show me ldd /usr/local/lib/libdispatch.so.0
>
> I saw the same problem here is my ldd /usr/local/lib/libdispatch.so.0
> and /etc/make.conf for you reference.
>
> root@ketagalan:~ # uname -a
В Tue, 22 Apr 2014 16:18:39 +0300
Arto Pekkanen пишет:
> Wow, sounds cool! I just wanted to say thank you for researching
> something not officially researched elsewhere :)
>
> You could fork the current X.org port, and maintain a partial ports
> tree in a separate repository. Then people intere
On Sun, Apr 20, 2014 at 08:05:34PM +0300, Ivan Klymenko wrote:
> Hi all.
>
> You are tired of frequent friezes xorg server?
> Are you bored messages in /var/log/Xorg.0.log:
> "
> ...
> [mi] EQ overflowing. Additional events will be discarded until existing
> events are processed.
> ...
> "
> ?
>
Have you tried applying these changes to 1.15? Almost all the patches fail
- but I have traditionally been very bad at working with large patch files
so I might be going about it wrong...
NS
On Tue, Apr 22, 2014 at 6:18 AM, Arto Pekkanen wrote:
> Wow, sounds cool! I just wanted to say thank y
Wow, sounds cool! I just wanted to say thank you for researching something not
officially researched elsewhere :)
You could fork the current X.org port, and maintain a partial ports tree in a
separate repository. Then people interested in testing the X.org with GCD
support could easily use http
В Mon, 21 Apr 2014 11:30:56 +0200
Niclas Zeising пишет:
> On 04/20/14 19:05, Ivan Klymenko wrote:
> > Hi all.
> >
> > You are tired of frequent friezes xorg server?
> > Are you bored messages in /var/log/Xorg.0.log:
> > "
> > ...
> > [mi] EQ overflowing. Additional events will be discarded unti
Hi all.
You are tired of frequent friezes xorg server?
Are you bored messages in /var/log/Xorg.0.log:
"
...
[mi] EQ overflowing. Additional events will be discarded until existing events
are processed.
...
"
?
:)
Then you here! :)
Patch attached :)
If you like, we can continue to develop thi
13 matches
Mail list logo
