use Perl Journal Search

Finally, some Test::Builder2 examples! (2010.09.09 3:33)

schwern — 2010-09-09T08:33:42+00:00

For my PDX.pm presentation tonight on Test::Builder2 I threw together some quick examples of some of its killer features, in particular demonstrating changing how Test::Builder2 behaves using method modifiers and applying object roles.

First, demonstrating end-of-assert actions, there's die on fail but even cooler is DEBUG on fail! That's right, run your test in the debugger and have it automatically set a breakpoint on a failure. How cool is that?

I'm sure somebody with better debugger foo than I can make it even cooler and stop at the top of the assert stack rather than inside DebugOnFail.

The second is reimplementing Test::NoWarnings safely. TB2::NoWarnings demonstrates hooking into the start and end of the test as well as safely altering the number of tests planned by trapping the call to set_plan.

You can safely use them all together, though its a crap shoot if DebugOnFail or DieOnFail will trigger first.

While roles and method modifiers are relatively new to the Perl community, using them in lieu of designing my own event system for TB2 has two great advantages. First, I didn't have to design and debug my own event system. :) Second, rather than having to learn the quirks of a one-off system, you learn the quirks of Mo[uo]se and then can apply that knowledge all over the place.

There's a pile of stuff to be done in TB2, a lot of them are fairly small and self contained. Have a look. Patches welcome.

Test::Builder2 at 10k Feet (2010.09.09 3:15)

schwern — 2010-09-09T08:15:22+00:00

Here's a diagram of the "flow" of assert results through Test::Builder version 1.

.-------. | foo.t | '-------' | | .-------------. | .----------------. | Test::More |<--------->| Test::Whatever | '-------------' '----------------' | | | | | | | .---------------. | '---->| Test::Builder |<----' '---------------' | v .-----. | TAP | '-----' | v .---------------. | Test::Harness | '---------------'

You write foo.t using Test::More and Test::Whatever. These both
use the same Test::Builder object. It spits out TAP which
Test::Harness converts into something human readable.

The big problem there is Test::Builder is monolithic. There's no
further breakdown of responsibilities. It only spits out TAP, and
only one version of TAP.

Here's what Test::Builder2 looks like:

.-------. .----------------| foo.t |-------------------. | '-------' | | | | | | | v v v .------------. .----------------. .------------------. | Test::More | | Test::Whatever | | Test::NotUpdated | '------------' '----------------' '------------------' | | | | v v | .----------------. .---------------. '---------->| Test::Builder2 |<------| Test::Builder | '----------------' '---------------' | v .--------------. .-------------. | TB2::History |<---| TB2::Result | '--------------' '-------------' | | .--------------------------. | .---------------------. | TB2::Formatter::TAP::v13 |<-----'------>| TB2::Formatter::GUI | '--------------------------' '---------------------' | | v | .-------------------------------. | | TB2::Formatter::Streamer::TAP | | '-------------------------------' | | | v | .-----. | | TAP | | '-----' | | | v v .---------------. .-----------------. | Test::Harness | | Pretty Pictures | '---------------' '-----------------'

It starts out the same, foo.t uses a bunch of test modules
including Test::More and Test::Whatever using the same Test::Builder2
object, but it also uses Test::NotUpdated which is still using
Test::Builder. That's ok because Test::Builder has been rewritten in
terms of Test::Builder2 (more on that below).

Test::Builder2, rather than being a monolith, produces a
Test::Builder2::Result object for each assert run. This gets stored
in a Test::Builder2::History object for possible later use. It also
gets handed to a Test::Builder2::Formatter object, the default is
Test::Builder2::TAP::v13 which produces TAP version 13. This is fed
to a Streamer that prints it to STDOUT and STDERR which is read by
Test::Harness and made human readable.

Because Test::Builder2 is not monolithic, you can swap out parts. For
example, instead of outputting TAP it could instead hand results to a
formatter that produced a simple GUI representation, maybe a green
bar, or something that hooks into a larger GUI. Or maybe one that
produces JUnit XML.

Here's how Test::Builder and Test::Builder2 Relate.

.-----. .-----. | TB2 | | TB1 | '-----' '-----' | | | | | | | | v v .-------------. .--------------. .-------------. | TB2::Result |------->| TB2::History |<--------| TB2::Result | '-------------' '--------------' '-------------' | | | | | | | .----------------. | '------------->| TB2::Formatter |<--------------' '----------------' | v .--------. | Output | '--------'

Test::Builder and Test::Builder2 coordinate their actions by sharing
the same History and Formatter objects. If you call TB1->ok() it
produces a Result object which it hands to the History singleton and
the Formatter singleton. If you call TB2->ok() it produces a Result
object which it hands to the same History and Formatter objects.

This allows most of the Test::Builder code to remain the same while
still coordinating with Test::Builder2. It also allows radically
different builders to be made without Test::Builder2 dictating how
they're to work.

The downside is that roles applied to Test::Builder2 will not effect
Test::Builder. Because of this, Test::Builder may become more closely
coupled with Test::Builder2 in the future.

Diagrams by App::Asciio.

DBD::SQLite 1.31 releasing next week and may break your code (2010.09.08 21:11)

Alias — 2010-09-09T02:11:54+00:00

After 6 or 7 months (mainly waiting around for the next "recommended upgrade instruction" from the SQLite project) the latest DBD::SQLite release should occur next week.

You can get the 1.30_06 release candidate from the CPAN, or from the following URL if your mirror hasn't synced yet.

http://svn.ali.as/cpan/releases/DBD-SQLite-1.30_06.tar.gz

Apart from the normal batch of SQLite upgrades (from 3.6.22 to 3.7.2), bug fixes, and minor enhancements, this release has two changes that may break your code.

These changes have been in the dev releases for some time, but you may want to take the opportunity to test more intensively if you use either of the following features.

1. BLOB columns with UTF8 content

- Resolved #54271: Inserting a string with utf-8 flag on corrupts BLOB data; now BLOB data is always stored as bytes (without the utf-8 flag) even if it has the flag set (ISHIGAKI)

2. FTS3 queries

- Added support for FTS3 tokenizers written in Perl. Added tests and documentation on how to use FTS3. Changed compilation flag to use the recommanded -DSQLITE_ENABLE_FTS3_PARENTHESIS *** MAY POSSIBLY BREAK OLD APPLICATIONS THAT ALREADY USED FTS3 *** (DAMI)

If you are currently using FTS3, please see DBD::SQLite::FTS3Transitional which contains a helper function for automatically upgrading old FTS3 queries to the new syntax.

use Perl; Shutting Down Indefinitely (2010.09.08 17:07)

pudge — 2010-09-08T22:07:47+00:00

See here.

The Pugs repository is dead; long live Mu! (2010.09.06 1:30)

masak — 2010-09-06T06:30:29+00:00

This weekend marks the end of a quite astonishing era. The Pugs repo, that hosted all the amazing Perl 6 activity, is no more. At its height, this repository had 242 committers! I just checked.

The Pugs repository has functioned as a common writing area for Perl 6-related things. First Pugs; then a lot of external modules and scripts written in Perl 6; what would eventually morph into the Perl 6 test suite; even the Perl 6 specification and the standard grammar. Commit bits (write access credentials) were handed out liberally, and newcomers were encouraged to help improve things they found amiss. The degree to which this system worked without a hitch has been quite astonishing. There have been no edit wars, no vandalism, no banning. Just the continuing flow of commits. Trust the anarchy.

So why are we killing off the Pugs repository? Well, technologies come and go; not so much because they worsen by each year, but because our expectations rise in a sort of software inflation. The SVN repository became too high-maintenance, and a transition to git was the natural next step. The Pugs repository has been split up into the git repositories linked to in the previous paragraph. Those bits that don't belong in any of the standard bins remain in the Mu repository. (Its name is a reference to the most-general object type in Perl 6, what in other languages is commonly known as 'Object'.)

I for one salute our new git-based overlords! May the commits keep flowing even under this new system. Also, moritz++ for carrying out the move.

Should Module::Install move to explicit plugin declaration? (2010.09.05 21:26)

Alias — 2010-09-06T02:26:06+00:00

Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.

With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.

For example, some random author that is trying to checkout a Catalyst project needs:

1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.

In the case of the former, you get the semi-cryptic but at least standard "Can't find inc/Module/Install.pm in @INC" message, so the error is resolvable.

But in the latter case, you're likely to get something like "Unknown command 'catalyst_ignore'", with no real obvious resolution mechanism.

I think this idea of automatic plugin discovery is starting to hit it's limits in terms of clarity.

And so I'd like to do something counter to my natural instincts here, and make M:I more verbose.

I'm thinking of something like the following for explicitly declaring the use of a non-core Module::Install extension.

use inc::Module::Install qw{ Catalyst XSUtil };

This would both allow M:I to error with a much more meaningful error when you don't have a plugin, and also prevent the loading of unused plugins which should prevent accidental plugin collisions (some of which I've seen occurring in the CPAN Testers machines).

Thoughts?

tomorrow, tomorrow (2010.09.05 16:54)

perl6doc — 2010-09-05T21:54:05+00:00

.. I will start officially my work on the grant. Friday I gave my very well recieved Perl 6 talk (German slides). I set some minds right about Perl 6. I explained whts the idea behing Perl and Perl 6, showed some syntactic sugar, tipped the idea of perl 6 as a meta language and said some words about the current state of implementations.

First mileston ist to write tablet 2 about variables in English (and German). As written under my proposal as comment, it will also appear in Perl6::Doc and therefore also in grop meaning the commandline on your computer, if you wish.

There are also some bits of the tablet 0 - history I'm currently thinking about. And I also want to develop with jens (as announced) some educanional material, which I hope will also be stored in gabors git repo for further reuse.

All these things benefit from each other and YOU can of course contribute if you like.

DC Perl Mongers Rakudo Star Pizza Party Meeting (2010.09.03 19:50)

awwaiid — 2010-09-04T00:50:48+00:00

We're starting our usual monthly DC Perl Mongers meeting a bit early this Tuesday (September 7th) to have a little pizza and celebrate Rakudo-Star! Arrive at 6:30pm at the Starbucks at 18th and K Street NW (call me, Brock, if you miss us and need to be let in, number on the website) if you want food. But feel free to wander in any time thereafter, we usually stay as late as 10:00pm. We'll swoop down and look for people at the normal 7:30pm time too :)

Other activities:

Bring your laptop!
Installing Rakudo-Star
Giving hands-on tutorials
Beginner and Advanced welcome!
Never been to DC.pm before? No problem, come have some free pizza!

Please put your name on http://dc.pm.org/Rakudo-Star_Party (or email the mailing list, which can be found at http://dc.pm.org/) so we know how much food to get.

If you have any questions, email the list or me directly -- awwaiid@gmail.com will do :)

About Rakudo Star: "Rakudo Star" is a useful and usable distribution of Perl 6. Current releases are aimed at "early adopters" of Perl 6. We can tell you ALL about it when you arrive :)

Pittsburgh Perl Workshop CFP ends Monday Sept 6 (2010.09.02 10:22)

rblackwe — 2010-09-02T15:22:01+00:00

The Pittsburgh Perl Workshop 2010 will be Saturday October 9 and Sunday 10 at the Gates Center at CMU.

Don't miss your chance to speak at this years Workshop. The Call For Papers ends Monday Sept 6.

Submit your talk.

Yapsi 2010.09 Released! (2010.09.01 17:31)

masak — 2010-09-01T22:31:48+00:00

It is with a peevish exultation of spirit that I announce on behalf of the Yapsi development team the September 2010 release of Yapsi -- soon to be a major motion picture -- a Perl 6 compiler written in Perl 6.

You can download it here (or, if you happen to be on an avian-carrier-based network, you can "pidgeon" it here).

Yapsi is implemented in Perl 6. It thus requires a Perl 6 implementation to build and run. This release of Yapsi has been confirmed to work on both Rakudo Star 2010.08 and Rakudo Star 2010.07.

Yapsi is an "official and complete" implementation of Perl 6. Yapsi's official status has been publicly confirmed by Patrick Michaud, the Rakudo pumking. The claim about Yapsi being complete... well, it might just be what PR people sometimes refer to as "a slight exaggeration". On the bright side, it's becoming less so with each new release.

This month's release brings you unless and until, as well as our-scoped variables:

$ yapsi -e 'my $a = 0; unless $a { say 42 }' 42

$ yapsi -e 'my $a = 0; until $a { say ++$a }' 1

$ yapsi -e 'our $a = 42; { my $a = 5; { say our $a } }' 42

For a complete list of changes, see doc/ChangeLog.

Quite a lot of features are within reach of people who are interested in hacking on Yapsi. See the doc/LOLHALP file for a list of 'em. In fact, that's how isBEKaml++ implemented 'unless' this month. (After which he exclaimed "that was easy!" and tackled 'until'.) If you're wondering whether you're qualified to help with the Yapsi project, that probably means you are.

Yapsi consists of a compiler and a runtime. The compiler generates instruction code which the runtime then interprets. In Yapsi, that instruction code (unfortunately) is called SIC[!]. Until further notice, SIC as a format changes with each monthly release for various, mostly good reasons. However, if you write a downstream tool that makes assumptions about the SIC format, someone might change it just out of spite. SIC is explicitly not compatible with later, earlier, or present versions of itself.

An overarching goal for making a Perl 6 compiler-and-runtime is to use it as a server for various other projects, which will hook in at different steps:

A time-traveling debugger (tardis), which hooks into the runtime.
A coverage tool (lid), which will also hook into the runtime.
A syntax checker (sigmund), which will use output from the parser.

Another overarching goal is to optimize for fun while learning about parsers, compilers, and runtimes.

Have the appropriate amount of fun!

Rakudo Star 2010.08 released (2010.09.01 7:36)

pmichaud — 2010-09-01T12:36:56+00:00

[This announcement was made last week on rakudo.org -- I'm reposting to use.perl.org so it will show up in the various Perl aggregators. --Pm]

On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the August 2010 release of "Rakudo Star", a useful and usable distribution of Perl 6. The tarball for the August 2010 release is available from http://github.com/rakudo/star/downloads.

Rakudo Star is aimed at "early adopters" of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These "Star" releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it.

In the Perl 6 world, we make a distinction between the language ("Perl 6") and specific implementations of the language such as "Rakudo Perl". The August 2010 Star release includes release #32 of the Rakudo Perl 6 compiler [1], version 2.7.0 of the Parrot Virtual Machine [2], and various modules, documentation, and other resources collected from the Perl 6 community.

This release of Rakudo Star adds the following features over the previous Star release:
* Nil is now undefined
* Many regex modifiers are now recognized on the outside of regexes
* Mathematic and range operations are now faster (they're still slow, but they're significantly faster than they were in the previous release)
* Initial implementations of .pack and .unpack
* MAIN can parse short arguments
* Removed a significant memory leak for loops and other repeated blocks

This release (temporarily?) omits the Config::INI module that was included in the 2010.07 release, as it no longer builds with the shipped version of Rakudo. We hope to see Config::INI return soon.

There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Thus, we do not consider Rakudo Star to be a "Perl 6.0.0" or "1.0" release. Some of the not-quite-there features include:
* nested package definitions
* binary objects, native types, pack and unpack
* typed arrays
* macros
* state variables
* threads and concurrency
* Unicode strings at levels other than codepoints
* pre and post constraints, and some other phasers
* interactive readline that understands Unicode
* backslash escapes in regex character classes
* non-blocking I/O
* most of Synopsis 9
* perl6doc or pod manipulation tools

In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed.

See http://perl6.org/ for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. An updated draft of a Perl 6 book is available as in the release tarball.

The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compiler@perl.org mailing list, or join us on IRC channel #perl6 on freenode.

Rakudo Star releases are created on a monthly cycle or as needed in response to important bug fixes or improvements. The next planned release of Rakudo Star will be on September 28, 2010.

[1] http://github.com/rakudo/rakudo
[2] http://parrot.org/

A month of Test::Builder2 (2010.08.27 23:08)

schwern — 2010-08-28T04:08:39+00:00

I've had a grant open for Test::Builder2 for, oh god over two years now. Since I started it, Perl 6 has had a release! I think its the second oldest running dev grant.

I've cleared the decks of other responsibilities and can dedicate September to, if not finishing, then at least releasing something people can poke at. First alpha release was supposed to be "two weeks after the start" ha ha ha! oh god. The design has evolved and simplified greatly in the intervening two years, but its time to get something the hell out the door. At least a Test::Builder2 Star if you will.

There's critical components missing. There's no diagnostics, YAML or otherwise. The issues with nested asserts are still congealing. Plans are not enforced. Result objects are in the middle of being remodeled... again. But Test::Builder is using what parts of Test::Builder2 are usable. Multiple output formats and streams work. Asserts can be nested in the common, simple cases without having to fiddle with $Level. And you can hook into various events.

Step one is I'm going to seal up what's there, write docs where they're missing, and release something.

A release before October or the grant dies.

Idiomatic Perl 6 (2010.08.26 19:22)

masak — 2010-08-27T00:22:03+00:00

So, I wrote a program to generate Pascal's triangle. The first ten rows of the triangle, at least. It only used simple features of Perl 6, such as scalars, nested arrays, and for loops.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current; push @current, @last[0]; for 0 .. @last - 2 { push @current, @last[$_] + @last[$_ + 1]; } push @current, @last[ * - 1 ]; push @pascal, [@current]; } say @pascal.perl;

In fact, save for simple mechanically substitutable differences, it could have been a Perl 5 script. In fact, with a bit of manual array allocation, it could have been a C script. That's OK; there's a tolerance in the Perl community of writing code that looks like it was thunk in some other language.

But I've heard that Perl 6 is great at doing things with operators. For example, the Z operator, which interleaves two lists, seems to be able to help me write my push statements more succinctly:

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current; for (0, @last) Z (@last, 0) -> $left, $right { push @current, $left + $right; } push @pascal, [@current]; } say @pascal.perl;

The parentheses before and after the infix:<Z> aren't necessary, because the Z operator has looser precedence than comma. They're just shown here to make your eyes accustomed to reading this construct.

In fact, now that only the addition is performed in the inner loop, I might as well use the Z+ operator, which does this for me.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current = 0, @last Z+ @last, 0; push @pascal, [@current]; } say @pascal.perl;

Now as the remaining loop shrinks to a size I can take in all at once, I see a bit more clearly what I'm doing: I'm building each new list from the previous one. I could feed the previous list into a named function to get the current one:

my $ELEMENTS = 10; my @pascal = [1]; sub next-list(@p) { [0, @p Z+ @p, 0] } for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; my @current = next-list(@last); push @pascal, @current; } say @pascal.perl;

Or I could just feed it into a in-place anonymous sub.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; push @pascal, (sub (@p) { [0, @p Z+ @p, 0] }).(@last); } say @pascal.perl;

But why even a sub? Perl 6 has a lighter construct, namely a "pointy block" (also known as a "closure" or a "lambda"). It doesn't participate in the call stack, and it's slightly easier to write.

my $ELEMENTS = 10; my @pascal = [1]; for 1 .. $ELEMENTS - 1 { my @last = @pascal[ * - 1 ].list; push @pascal, (-> @p { [0, @p Z+ @p, 0] }).(@last); } say @pascal.perl;

Let's look at what the code does. Seed with one element. Calculate the next element based on the previous one. Stop at some point.

But that's exactly what the series operator does. The one that's written with three dots. We have a starting value, a way to get from one value to the next (our code block above), and a stopping value.

Well actually, we don't have the stopping value. But that's OK, since the series operator is lazy. So if we only request the first 10 values, it won't loop forever giving us the rest of the list.

my @pascal := do [1], -> @p { [0, @p Z+ @p, 0] } ... *; say @pascal[^10].perl;

(The extra do required because of a shortcoming in Rakudo.)

Now. Something very much like this code was posted first on Rosetta code and then on Moritz' blog. (TimToady used a sub, but said later that he'd have preferred binding.)

A couple of Perl 5 people's reactions were — somewhat uncharacteristically — of a negative flavour, similar to how people seem to react to the periodic table of operators:

@shadowcat_mst: an excellent example of why I consider camelia perl to be a language research project more than a production language

@pedromelo: I'm seriously considering this post as an example of what I don't want Perl6 to become...

I think these reactions are mainly feature shock. Higher-order operators, pointy blocks, and the series operator... they're all good, well-established features, which find daily use in Perl 6 programs. Maybe using them all together like that flung some people off the deep end. Never mind that the resulting script is all essential complexity, with virtually no boilerplate from the original script left.

This is the first time that's happened. I think it's important to listen to what Perl 5 people think and to try to respond to that. But I also think that this time, it's a case of them seeing some highly idiomatic Perl 6, and freaking out a bit.

And I think that that, in some odd sense, is a good thing. Well, not freaking people out, per se. But the fact that we did shows that there's something forming which might be tentatively called "idiomatic Perl 6": people on the inside can read it quite easily, but those on the outside, even Perl 5 folks looking in, instinctively go "eeeeew!".

That's OK. You're not meant to start with the idiomatic stuff. Language acquisition takes place step by step, and that goes for learning Perl 6 as well. On the way there, just don't confuse distaste with lack of familiarity.

Amiga Ethernet (2010.08.25 15:09)

scrottie — 2010-08-25T20:09:48+00:00

Yesterday, I got my X-Surf 3cc Ethernet card I broke down and ordered for my Amiga 3000. There's some backstory about serial consoles, Sparcs, and the cluster, but it's not important. The 3000 was also packaged as a Unix machine, running a pretty standard port of SysV. It was the first Amiga standard with an MMU and SCSI. It'll also kick out 1280x resolution graphics at 2bpp. Commodore sold an Ethernet board for it along with Unix on tape.

The X-Surf is really an ISA card, probably NE2000, mounted in a little carrier. There are confusingly few pins attached and the logic on the carrier amounts to a few small 7400 series chips and one slightly larger chip that also couldn't possibly have enough logic on it to do what it does. And then just to convince you that your nuts, it adds an IDE port that alone has more lines than the one little adapter chip does. The Amiga really is a machine for psychopaths, by psychopaths. Everyone sits around all of the time trying to out psycho everyone else. Just take a look at the demo scene for the thing. Amiga virtually defined the demo scene.

I have/had Amiga OS 3.9 on the thing. 3.9 is post-Commodore death. Someone bought the rights and sold them and someone bought them and sold them and so on until a sue happy band of self righteous ruffians managed to convince the remaining user base buying the rights at garage sale prices entitled them to be king of the squalid kingdom so that they could go around lynching anyone else trying to do anything for the Amiga. Anyway, OS 3.9 is pretty recent as far as Amiga stuff goes, even though it's ten years old. Most people stopped at 3.1. 3.9 only came out on CD-ROM. The 3000 doesn't have a bay but it does have SCSI, so the CD-ROM, when needed, gets hung off the side with the case open. I could also set up an enclosure and plug it into the back. I could also probably buy one of those.

X-Surf's stuff did not want to install.

X-Surf actually had an installer, which is impressive. AmigaOS 3.x has a scripting language for installers and an interpreter for that. This installer gave you the choice of two TCP stacks. AmigaOS 3.9 comes with a TCP stack but you can still swap it out. It's a bit Windows 3.1-like in that regard. The options are GENESiS/AmiTCP and Miami. GENESiS, the AmiTCP configurerer and dialer that cames with AmiTCP, was shipped in a version requiring libraries not included in AmigaOS3.9 so it wouldn't run. AmiTCP would, and AmiTCP was on the HD, though buried a bit. Miami is shareware/crippleware. It required the same library, MagicUI, that I didn't have.

I spent hours sorting out what required what and what I did and didn't have and how these various packages worked and fit together. That's ignoring the device driver for the ethernet card which is straight forward. The Amiga has a directory for libraries (which end in .library; the Unix terseness is missing from AmigaOS even though a lot of the feel is there). AmigaOS3.9 also won't read iso9660 filesystem CDs. Perhaps some BoingBag update fixes that but the BoingBag updates themselves are large .lha archives. I'm avoiding plugging the serial line into a Unix machine and speaking kermit or zmodem or something to transfer stuff. I've been down that road. Eventually I burned AmigaSYS4, a version of AmigaOS3.9 with lots of add-ons and the various BoingBag updates on it, stick it in the Amiga, and was able to steal MUI off of it and get both TCP stacks running.

Amiga programmers love to do ports of Unix software and add GUIs. They've been doing this for ages. They've had gcc since the early ages of gcc, and I ran the Amylaar MUD driver on AmigaOS 1.3 to do development locally, also in the dark ages. Kicking around on aminet.net from the Amiga, I see PHP, MySQL, Apache, bittorrent, Python, bind9, samba, VNC, and all sorts of stuff. No one ports just the client. If they port the client, they port the server, too. In the case of AmiTCP, the suite of utilities you'd expect are there, such as host, finger, traceroute, and so on, but to configure TCP/IP, you run a little GUI program and it asks you questions. It took Linux ages to get to this point and Amiga was doing it long before. One of the extras on the Extras disc, even as far back as 1.3, was a version of emacs with drop down menus.

Completely unsurprisingly, the 16mhz 68030 processor running AWeb (which does some JavaScript) is vastly faster than firefox on my 1.2ghz Centrino Linux machine. Amiga programmers do not write slow software. It's entirely against their nature. Threading is fantastic. It'll do downloads, render several jpgs in the page, update the page layout as HTML comes across, and never lose snappy UI responsiveness. On firefox, I yank on the scrollbar only to have it ignore me and snap back, or else the scroll bar doesn't move at all, or the whole thing just goes away for a few heart sinking seconds, making me wonder if it just crashed.

My ambition is to get a desk in a shared office space going and stick this baby there with an updated video card that does high res, high bit depth graphics. If I'm willing to start replacing and upgrading chips on the motherboard, I can take the thing up to a gig of RAM, too, and NetBSD supports it if I ever decide I want to see how firefox runs on a 16mhz processor. What I'm really hoping for is someone to take the latest Coldfire chips from Motorola's spin off, Freescale, and do an 800mhz accelerator card for the Amiga 2000/3000/4000. That would RULE.

-scott

Austrian Perl Workshop 2010 - Call for papers (2010.08.25 4:34)

daxim — 2010-08-25T09:34:44+00:00

English below

――――

Wir rufen zum Einreichen von Vorträgen und Workshops für den österreichischen Perlworkshop 2010 auf, der am 5.–6. November in Wien stattfinden wird. Wir möchten gerne eure Themen über die Sprachfamilie Perl und damit verbundenes erfahren. Der Stichtag dazu ist der 8. Oktober.

Um einen Vorschlag einzureichen und für weitere Details, siehe unsere Website. Bitte abonniert den Feed für zukünftige Benachrichtigung.

Die Orgas

――――

We are announcing the call for papers for talks and workshops for the Austrian Perl Workshop 2010 which will be held on November 5th–6th in Vienna. We would like to hear about your ideas concerning the Perl family of languages and related topics. The deadline for submissions is October 8th.

To submit a talk abstract and for further details visit our web site. Please subscribe to the newsfeed to stay updated.

The organisers