Hey Göran, just thought I'd drop you a note. Always a happy day, the
day of ordering and, even better, taking delivery of, a new ThinkPad.
Just wanted to share my excitement with you because -- you sort of
opened my eyes!
You were totally right about the x220/x230's -- like a dinky stick of
dynamite! Although I think carbon fiber is a great material for a
laptop as much as a mountain bike, I took a deeper look at the X1 and
found only ULV processor options, no mSATA capability, no battery
options, no upgradeability. Maybe good for e-reading in a coffee
shop, maybe they should have called it ThinkMac instead? ha! No
seriously there don't seem to be many high performance ultra-book
sized laptops at all out there. I'm running big Magma apps, I want
power! So with fast processor and 256GB mSATA for the OS I spare the
HD bay for a 750GB hybrid SSD drive to handle big apps. Server power
on the road!
Ok, sorry for rambling but one more thing: I _really_ struggled with
this choice but in the end I decided to get the heavier/bulkier
multitouch tablet version (X230t). This is just ultra-cool tech and
once I saw it mostly works in Ubuntu, now I've got to know if it can
increase my input "connection" to Maui apps and other apps too.
Cheers!
Chris
On Tue, Jan 8, 2013 at 2:04 AM, Göran Krampe <goran(a)krampe.se> wrote:
> Hey!
>
>
> On 01/07/2013 04:33 PM, Chris Muller wrote:
>>
>> My dream machine is:
>>
>>
>> http://www.lenovo.com/products/us/laptop/thinkpad/x-series/x1-carbon-touch/
>
>
> Sliding a bit from Jecel's original request - because I think he was
> shopping for something less expensive - but I have a Lenovo X220 since april
> and I just love it. And it runs Linux perfectly, wrote a bit about it:
>
> http://goran.krampe.se/2012/04/14/going-lenovo/
>
> ...now, since the X230 is out it seems the price of X220 has dropped a bit
> too.
>
> regards, Göran
>
> PS. The IPS panel, the keyboard and the expansion options (memory, battery,
> hdd etc) are probably the major points.
>
On 27 April 2013 21:24, <commits(a)source.squeak.org> wrote:
> Levente Uzonyi uploaded a new version of Tests to project The Trunk:
> http://source.squeak.org/trunk/Tests-ul.200.mcz
>
> ==================== Summary ====================
>
> Name: Tests-ul.200
> Author: ul
> Time: 27 April 2013, 10:08:43.206 pm
> UUID: dfe70287-0768-42f9-97b7-d7ba6fbd6bb6
> Ancestors: Tests-fbs.199
>
> - avoid suboptimal string concatentation in ReleaseTest >> #testMethodsWithUnboundGlobals
And "asCommaString" is more intention revealing. More insight into the
failing test at
http://build.squeak.org/job/SqueakTrunk/281/testReport/junit/Tests.Release/…
(Warning: it's pretty big.)
It's possible that this test is showing that every single method in
every single class has unbound globals. That's highly indicative of a
bug in the SystemNavigation >> #methodsWithUnboundGlobals. Well, not
_there_. Perhaps the bug starts from "m methodClass bindingOf: l key"?
frank
Ah, I just did that in my Pharo copy!
2013/4/27 <commits(a)source.squeak.org>
> Levente Uzonyi uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-ul.755.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-ul.755
> Author: ul
> Time: 27 April 2013, 10:07:32.072 pm
> UUID: 7acc79da-c279-4097-a56f-7d44c94aa5f7
> Ancestors: Kernel-fbs.754
>
> Added two methods to access primitive 240 and 241, which can provide
> microsecond resolution timestamps on Cog VMs.
>
> =============== Diff against Kernel-fbs.754 ===============
>
> Item was added:
> + ----- Method: Time class>>primLocalMicrosecondClock (in category
> 'clock') -----
> + primLocalMicrosecondClock
> + "Answer the local microseconds since the Smalltalk epoch. The
> value is derived from the Posix epoch with a constant offset corresponding
> to elapsed microseconds between the two epochs according to RFC 868, and
> with an offset duration corresponding to the current offset of local time
> from UTC."
> +
> + <primitive: 241>
> + ^0!
>
> Item was added:
> + ----- Method: Time class>>primUTCMicrosecondClock (in category 'clock')
> -----
> + primUTCMicrosecondClock
> + "Answer the UTC microseconds since the Smalltalk epoch. The value
> is derived from the Posix epoch with a constant offset corresponding to
> elapsed microseconds between the two epochs according to RFC 868."
> +
> + <primitive: 240>
> + ^0!
>
>
>
Levente Uzonyi uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-ul.755.mcz
==================== Summary ====================
Name: Kernel-ul.755
Author: ul
Time: 27 April 2013, 10:07:32.072 pm
UUID: 7acc79da-c279-4097-a56f-7d44c94aa5f7
Ancestors: Kernel-fbs.754
Added two methods to access primitive 240 and 241, which can provide microsecond resolution timestamps on Cog VMs.
=============== Diff against Kernel-fbs.754 ===============
Item was added:
+ ----- Method: Time class>>primLocalMicrosecondClock (in category 'clock') -----
+ primLocalMicrosecondClock
+ "Answer the local microseconds since the Smalltalk epoch. The value is derived from the Posix epoch with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868, and with an offset duration corresponding to the current offset of local time from UTC."
+
+ <primitive: 241>
+ ^0!
Item was added:
+ ----- Method: Time class>>primUTCMicrosecondClock (in category 'clock') -----
+ primUTCMicrosecondClock
+ "Answer the UTC microseconds since the Smalltalk epoch. The value is derived from the Posix epoch with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868."
+
+ <primitive: 240>
+ ^0!
Hi all,
Recently I've developed Sqnappy - Squeak/Pharo binding of the snappy
compressor library.
https://github.com/mumez/sqnappy
About snappy:
https://code.google.com/p/snappy/
Sqnappy is easy to use. You can just send #compress:, #uncompress to SnappyCore:
compressed := SnappyCore compress: data.
uncompressed := SnappyCore uncompress: compressed.
With a simple test, Sqnappy was 10.8x faster than the existing
GZipWriteStream/GZipReadStream.
Additionally, Sqnappy implements snappy framing format, so that it can
treat big data with a small memory allocation.
About framing format:
https://code.google.com/p/snappy/source/browse/trunk/framing_format.txt
Tested from a workspace, 1.3 GB pg_dump file was compressed in around
10 seconds and decompressed in 6.5 seconds . No annoying GCs. It was
comfortable.
Enjoy!
--
[:masashi | ^umezawa]