Forums

I've been trying various ways to access files in my PAW account, today I tried to modify a file using TRAMP in Emacs, this basically provides a way to seamlessly modify remote files in a local emacs using ssh and various other protocols.

On trying to open a file I get the following error message.

byte-code: Couldn't find a POSIX `id' command

OTOH git, sftp and scp are working well.

Keep up the good work :D

I'm not too surprised that the id command is missing, it's a bit of an obscure one. That said it should be harmless and easy to add, since it just prints the current and effective user and group IDs (or something like that).

Hopefully the PA boffins might be able to squeeze it into an upcoming update.

That sounds like a good idea. I'm a little surprised that it's not there already, to be honest.

It's on it's way -- just needs to go through testing now.

<--- taps foot waiting for testing...j/k

The problem with adding more and more features and keeping continuous integration running is that full tests take longer and longer... especially with some of our tests, which interface with PayPal and sometimes have to re-run themselves three or four times before they avoid getting some kind of server bug-out from their sandbox environment :-(

Oh dear, sounds like a distributed testbed might be required before long. They're not that tough to put together, but I would recommend trying to do it properly the first time rather than cutting corners - I've seen people put together a nice pool of hosts but then skimp on the scheduling logic and try some manual assignment of tests based on their assumptions about how long tests will take.

Instead, if you need to go this route, I suggest just a big pool of tests and then allocate them to hosts from a pool as and when the hosts become available. It's actually pretty efficient if you keep each host with one running test and one queued test - that means you've got all the time the test takes to run to get another test queued up locally.

The biggest PITA is usually the UI for queuing up a test run and the job of getting the code to test put everywhere. It's not intrinsically hard, just the fiddly sort of problem which is heavily dependent on your source control system, etc. Plus it's a big step from being able to run tests on your local host, which is the sort of convenience people get used to.

EDIT

Or just speed up the existing tests, I suppose. Bit of an "or we could use the teleporter" moment. (^_^)

Right, we actually had something like that for an earlier product and it was pretty nice. I'll have to see if we can resurrect the code.

ooooooooooooooooo...Zombie code.

Well, I think some of it was in Haskell so there's a very real possibility of it eating people's brains...

goo...er...giggles...NICE...☺