Charles Plessy: nodejs-legacy
apt install nodejs-legacy if you want npm install to work.
apt install nodejs-legacy if you want npm install to work.
[95474.561491] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[95474.803578] r8169 0000:0f:00.0 eth0: link down
[95474.803627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[95474.933797] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[95477.111599] wlan0: authenticate with 00:03:7f:fe:00:02
[95477.127389] wlan0: send auth to 00:03:7f:fe:00:02 (try 1/3)
[95477.129315] wlan0: authenticated
[95477.131352] wlan0: associate with 00:03:7f:fe:00:02 (try 1/3)
[95477.133605] wlan0: RX AssocResp from 00:03:7f:fe:00:02 (capab=0x411 status=0 aid=3)
[95477.133686] wlan0: associated
[95477.133703] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[99125.123138] device vethNLAABF entered promiscuous mode
[99125.123377] IPv6: ADDRCONF(NETDEV_UP): vethNLAABF: link is not ready
[99125.188568] IPv6: ADDRCONF(NETDEV_CHANGE): vethNLAABF: link becomes ready
[99125.188615] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99125.188631] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99140.239301] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99360.969652] [Firmware Bug]: battery: (dis)charge rate invalid.
[99361.729291] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[99361.864205] EXT4-fs (dm-2): re-mounted. Opts: errors=remount-ro,data=writeback,commit=0
[99361.905210] EXT4-fs (sda6): re-mounted. Opts: data=ordered,commit=0
[102236.267648] lxcbr0: port 1(vethNLAABF) entered disabled state
[102236.556452] lxcbr0: port 1(vethNLAABF) entered disabled state
[102236.557476] device vethNLAABF left promiscuous mode
[102236.557483] lxcbr0: port 1(vethNLAABF) entered disabled state
Time for another update on my work
for UEFI
improvements in Jessie!
I've spent more time on the integration of 32-bit grub-efi with a
64-bit Debian system, and just published a new test image on
pettersson. I've added:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512
I'm transitioning my GPG key from an old 1024D key to a new 4096R key.
The old key will continue to be valid for some time, but I prefer
all new correspondance to be encrypted to the new key, and will be making
all signatures going forward with the new key.
This transition document is signed with both keys to validate the transition.
If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
re-authenticating me.
Old key:
pub 1024D/0x5DD5685778D621B4 2000-03-07
Key fingerprint = 0F3C 34D1 E4A3 8FC6 435C 01BA 5DD5 6857 78D6 21B4
New key:
pub 4096R/0x1D661A372FED8F94 2013-12-30
Key fingerprint = 9A17 578F 8646 055C E19D E309 1D66 1A37 2FED 8F94
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlSwEaIACgkQXdVoV3jWIbQW5QCgoFHVU/D4fKSbvmGv3nNy3MAW
S2UAn075ztmxQ8Y9/22crbUug1sEjfh5iQIcBAEBCgAGBQJUsBGiAAoJEB1mGjcv
7Y+U9PgP/29jPvrNcdWsLI8YK9U6+JzS+TMXNyfp6CQXc8O/+zJwqvvxNpqY3rLM
5otRLIEJ2EVdiF8sCWTDGusS9NkMePzumR0AFAR0iltIkekO5O0HbHhK0sXJQv0s
EipDpFRO9k4/CBpJEy6Pkkxwd3ndtmwrL1/oKeVmM4E62PJd9ofMpQb/gMUsrA8u
F8xoOXY8Os82Rrd759PypSxNecjd6SYaVJTHgFbZ0QIMJkdKaufifzARdw+v5jwg
8Q11BhpYxvUSugZgiciKA6RjRK5bfRnT8VQPFd0zneilsIW13zz/jub9df/vtM5L
vY/6jHvXczYXSG8EGpHJQCD3KtQJPWZ0Nz9rAm4emEPmR2qav6KGARatYAm0RBqZ
Y81YUEuiWzGli6DH1m9SQe8bqM/J94vQAAX9VqUn2gz0Z0Ey25kVQE7NOGsbbGVS
vD/E74FSk1At9/RGpstrfEjsDKPRman2xk/oZe+08sRB22CJl40N4tZV9AkCJNom
HHGZKp+VEKaCEiLUIRjKTHt2HTThg39zmxl+OnoTSFYvloxrDJyi9SxZgCAmBhbD
7kLkaSDmdUj6CmoilGU+gd2zmQl2D+RHinYZBxOUf1vi1MDLWNcLIMgrz4mRXgzE
YKkG0newf9UbyJw42sXe2ukNQBIqBcL/DmAhG7V+r0RD7MQnMEYy
=09bN
-----END PGP SIGNATURE-----
The new key is available from keyservers, e.g. pgp.mit.edu or others.
In other news: Yes, I've not been blogging much recently, will try to do updates more often. In the mean time, you can also refer to my Twitter account for random stuff or the new sigrok Twitter account for sigrok-related posts.
I promised to write about this a long time, ooops... :-)
Another ARM port in Debian - yay!
arm64 is officially a release architecture for Jessie, aka Debian
version 8. That's taken a lot of manual porting and development effort
over the last couple of years, and it's also taken a lot of CPU time -
there are ~21,000 source packages in Debian Jessie! As is often the
case for a brand new architecture like arm64 (or AArch64, to use ARM's
own terminology), hardware can be really difficult to get hold of. In
time this will cease to be an issue as hardware becomes more
commoditised, but in Debian we really struggled to get hold of
equipment for a very long time during the early part of the port.
First bring-up in Debian Ports
To start with, we could use ARM's own AArch64 software models to
build the first few packages. This worked, but only very slowly. Then
Chen Baozi and the folks running
the Tianhe-2
supercomputer project in Guangzhou, China contacted us to offer access
to some arm64 hardware, and this is what Wookey used for bootstrapping
the new port in the
unofficial Debian Ports
archive. This has now become the normal way for new architectures to
get into Debian. We got most of the archive built in debian-ports this
way, and we could then use those results to seed the initial core set
of packages in the main Debian archive.
Second bring-up - moving into the main Debian archive
By the time that first Debian bring-up was
done, ARM was starting to produce its
own "Juno" development boards, and with the help of my boss^4 James
McNiven we managed to acquire a couple of those machines for use as
official Debian build machines. The existing machines in China were
faster, but for various reasons quite difficult to maintain as
official Debian machines. So I set up the Junos as buildds just before
going to DebConf in August 2014. They ran very well, and (for dev
boards!) were very fast and stable. They built a large chunk of the
Debian archive, but as the release freeze for Jessie grew close we
weren't quite there. There was a small but persistent backlog of
un-built packages that were causing us issues, plus the Juno machines
are/were not quite suitable as porter boxes for Debian developers all
over the world to use for debugging their packages on the new
architecture.
More horsepower - Linaro machines
This is where Linaro came to
our aid. Linaro's goal is to help improve Free and Open Source
Software on ARM, and one of the more recent projects in Linaro is a
cluster of
servers that are made available for software developers to use to
get early access to ARMv8 (arm64) hardware. It's a great way for
people who are interested in this new architecture to try things out,
port their software or indeed just help with the general porting
effort.
As Debian is seen as such an important part of the FLOSS ecosystem,
we managed to negotiate dedicated access to three of the machines in
that cluster for Debian's use and we set those up in October, shortly
before the freeze for Jessie. Andy Doan spent a lot of his time
getting these machines going for us, and then I set up two of them as
build machines and one as the porter box we were still needing.
With these extra machines available, we quickly caught up with the
ever-busy "Needs-Build" queue and we've got sufficient build power now
to keep things going for the Jessie release. We were officially added
to the list of release architectures at the Cambridge mini-Debconf in
November, and all is looking good now!
And in the future?
I've organised the loan of another arm64 machine from AMD for
Debian to use for further porting and/or building. We're also
expecting that more and more machines will be coming out soon as
vendors move on from prototyping to producing real customer
equipment. Once that's happened, more kit will be available and
everybody will be able to have arm64-powered computers in the server
room, on their desk and even inside their laptop! Mine will be running
Debian Jessie... :-)
Thanks!
There's been a lot of people involved in the Debian arm64
bootstrapping at various stages, so many that I couldn't possibly
credit them all! I'll highlight some, though. :-)
First of all, Wookey's life has revolved around this port for the
last few years, tirelessly porting, fixing and hacking out package
builds to get us going. We've had loads of help from other teams in
Debian, particularly the massive patience of the DSA folks with
getting early machines up and running and the prodding of the
ftpmaster, buildd and release teams when we've been grinding our way
through ever more package builds and dependency loops. We've also had
really good support from toolchain folks in Debian and ARM, fixing
bugs as we've found them by stressing new code and new machines. We've
had a number of other people helping by filing bugs and posting
patches to help us get things built and working. And (last but not
least!) thanks to all the folks who've helped us beg and borrow the
hardware to make the Debian arm64 port a reality.
Rumours of even more ARM ports coming soon are entirely
scurrilous... *grin*
Time for another update on my work
for UEFI
improvements in Jessie!
I now have a mixed 32- and 64-bit UEFI netinst up and running right
now, which will boot and install on the Asus X205TA machine I
have. Since the last build, I've added 64-bit (amd64) support and
added CONFIG_EFI_MIXED in the kernel so that the 64-bit kernel will
also work with a 32-bit UEFI
firmware. Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload2/
to download and test the image. There are a few other missing pieces
yet for a complete solution, but I'm getting there...!
WARNING: this CD is provided for testing
only. Use at your own risk! If you have appropriate
(U)EFI hardware, please try this image and let me know how you get on,
via the debian-cd and debian-boot mailing lists.
| Publisher: | Microsoft |
| Copyright: | June 2004 |
| ISBN: | 0-7356-1967-0 |
| Format: | Kindle |
| Pages: | 960 |
Code Complete is its sheer, mind-numbing
comprehensiveness. It tries to provide a set of guidelines and a
checklist to think about at each level of writing code. This is one of
those ideas that might sound good on paper, but which completely doesn't
work for me. There is no way I'm going to keep this many rules in my
head, in the form of rules, while programming. Much of good style has to
be done by feel, and the book I'm looking for is one that improves my feel
and my sense of taste for code.
What Code Complete seems to provide instead is a compilation of
every thought that McConnell has ever had about programming. There's a
lot of basic material, a few thoughtful statements, a ton of style advice,
an endless compilation of trade-offs and concepts that one should keep in
mind, and just a massive, overwhelming pile of stuff.
Each chapter (and there are a lot of chapters) ends in a checklist of
things that you should think about when doing a particular programming
task. To give you a feel for the overwhelming level of trivia here, this
is the checklist at the end of the chapter where I stopped reading, on
quality assurance in software. This is one picked at random; a lot of
them are longer than this.
I'm not saying those are bad things to think about with quality assurance, but you may notice a few issues immediately. They're very general and vague, they're not phrased in a particularly compelling or memorable way, and there are a lot of them. This falls between two stools: it's too much for the programmer who is thinking about quality as part of an overall project but not focusing on it (particularly when you consider that the book is full of checklists like this for everything from variable naming to how to structuring if statements to program debugging), but it's not nearly specific or actionable enough for someone who is focusing on quality assurance. It's not that the information isn't organized: there's a lot of structure here. And there are bits and pieces here that are occasionally interesting. McConnell is very data-driven and tries to back up recommendations with research on error rates and similar concrete measurements. It's just insufficiently filtered and without elegant or memorable summary. There is far too much here, an overwhelming quantity, and hopelessly mixed between useful tidbits and obvious observations that anyone who has been programming for a while would pick up, all presented in the same earnest but dry tone. It didn't help that there's a lot here I didn't agree with. Some of that is to be expected: I've never agreed completely with any style guide. But McConnell kept advocating variable and function naming conventions that I find rather ugly and tedious, and the general style of code he advocates feels very "bureaucratic" to me. It's not exactly wrong, but one of the things that I look for in style discussions is to be inspired by the elegant and simple way someone finds to phrase something in code. A lot of the code in this book just felt mind-numbing. It's functional, but uninteresting; perfectly adequate for a large project, but not the sort of discussion that inspires me to improve the quality of my craft. So, I didn't finish this. I gave up about halfway through. It's frustrating, since I was occasionally finding an interesting nugget of information. But they were too few and far between, and the rest of the book was mostly... boring. It's possible that I just know too much about programming to be the person for whom that McConnell was writing this book. It's certainly true that the book has not aged particularly well; it's focused on fairly old-school languages (C, C++, Java, and Visual Basic) and says almost nothing about modern language techniques, although it does have a bit about extreme programming. But whatever the reason is, it didn't work for me at all. I would rate it as one of the worst books about programming I've tried to read. And that's notably different enough from its reviews that it seems worth throwing this out there as a warning. I'm quite disappointed, since I'd heard nothing but praise for this book before picking it up. But it's not for me, and I'm now dubious of its value for any programmer outside of a fairly narrow, large-team, waterfall development process involving large numbers of people writing very large quantities of code in languages that aren't very expressive. And, well, in that situation I think one would get more benefit from changing that environment than reading this book. Rating: unfinished
- Have you identified specific quality characteristics that are important to your project?
- Have you made others aware of the project's quality objectives?
- Have you differentiated between external and internal quality characteristics?
- Have you thought about the ways in which some characteristics might compete with or complement others?
- Does your project call for the use of several different error-detection techniques suited to finding several different kinds of errors?
- Does your project include a plan to take steps to assure software quality during each stage of software development?
- Is the quality measured in some way so that you can tell whether it's improving or degrading?
- Does management understand that quality assurance incurs additional costs up front in order to save costs later?
| Publisher: | Pragmatic Bookshelf |
| Copyright: | 2005 |
| Printing: | May 2006 |
| ISBN: | 0-9745140-5-5 |
| Format: | Trade paperback |
| Pages: | 785 |
? and !
convention for methods that return booleans or modify objects in-place is
brilliant in its simplicity, and something I'd love to see in more
languages. And the way Ruby implements ubiquitous code blocks for both
iterators and for any temporary objects is lovely once one gets used to
it. It's similar to Python's context managers, except more general and
built deeper into the language. Returning to the review of the book,
rather than the topic, Programming Ruby has a good, clear
explanation of blocks, iterators, and yield.
If you're interested in getting a grounding in Ruby, this book still feels
like a solid introduction. The edition I read is getting a bit long in
the tooth now that we're on Ruby 2.1, but the pace of language change has
slowed, and most of the book is still applicable. (If you're buying it
new, you should, of course, get the later edition.) The table of contents
makes it seem like the book is covering the same ground multiple times,
but that organizational strategy worked better than I expected. Ruby is
not the most organized language in the world, so I still felt a bit
overwhelmed with random method names in places, but I never felt lost in
the mechanics of the language.
In short, recommended if you want a good introduction to the language,
although probably in a later edition.
Rating: 8 out of 10
To work with GnuPG and smartcards you install GnuPG agent, scdaemon, pscsd and pcsc-tools. On Debian you can do it like this:
apt-get install gnupg-agent scdaemon pcscd pcsc-toolsUse the
pcsc_scan command line tool to make sure pcscd recognize the smartcard before continuing, if that doesn t recognize the smartcard nothing beyond this point will work. The next step is to make sure you have the following line in ~/.gnupg/gpg.conf:
use-agentLogging out and into GNOME should start gpg-agent for you, through the
/etc/X11/Xsession.d/90gpg-agent script. In theory, this should be all that is required. However, when you start a terminal and attempt to use the smartcard through GnuPG you would get an error like this:
jas@latte:~$ gpg --card-status gpg: selecting openpgp failed: unknown command gpg: OpenPGP card not available: general error jas@latte:~$The reason is that the GNOME Keyring hijacks the GnuPG agent s environment variables and effectively replaces
gpg-agent with gnome-keyring-daemon which does not support smartcard commands (Debian bug #773304). GnuPG uses the environment variable GPG_AGENT_INFO to find the location of the agent socket, and when the GNOME Keyring is active it will typically look like this:
jas@latte:~$ echo $GPG_AGENT_INFO /run/user/1000/keyring/gpg:0:1 jas@latte:~$If you use GnuPG with a smartcard, I recommend to disable GNOME Keyring s GnuPG and SSH agent emulation code. This used to be easy to achieve in older GNOME releases (e.g., the one included in Debian Wheezy), through the
gnome-session-properties GUI. Sadly there is no longer any GUI for disabling this functionality (Debian bug #760102). The GNOME Keyring GnuPG/SSH agent replacement functionality is invoked through the XDG autostart mechanism, and the documented way to disable system-wide services for a normal user account is to invoke the following commands.
jas@latte:~$ mkdir ~/.config/autostart jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-gpg.desktop ~/.config/autostart/ jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-gpg.desktop jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/ jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop jas@latte:~$You now need to logout and login again. When you start a terminal, you can look at the
GPG_AGENT_INFO environment variable again and everything should be working again.
jas@latte:~$ echo $GPG_AGENT_INFO /tmp/gpg-dqR4L7/S.gpg-agent:1890:1 jas@latte:~$ echo $SSH_AUTH_SOCK /tmp/gpg-54VfLs/S.gpg-agent.ssh jas@latte:~$ gpg --card-status Application ID ...: D2760001240102000060000000420000 ... jas@latte:~$ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFP+UOTZJ+OXydpmbKmdGOVoJJz8se7lMs139T+TNLryk3EEWF+GqbB4VgzxzrGjwAMSjeQkAMb7Sbn+VpbJf1JDPFBHoYJQmg6CX4kFRaGZT6DHbYjgia59WkdkEYTtB7KPkbFWleo/RZT2u3f8eTedrP7dhSX0azN0lDuu/wBrwedzSV+AiPr10rQaCTp1V8sKbhz5ryOXHQW0Gcps6JraRzMW+ooKFX3lPq0pZa7qL9F6sE4sDFvtOdbRJoZS1b88aZrENGx8KSrcMzARq9UBn1plsEG4/3BRv/BgHHaF+d97by52R0VVyIXpLlkdp1Uk4D9cQptgaH4UAyI1vr cardno:006000000042 jas@latte:~$That s it. Resolving this properly involves 1) adding smartcard code to the GNOME Keyring, 2) disabling the GnuPG/SSH replacement code in GNOME Keyring completely, 3) reorder the startup so that gpg-agent supersedes gnome-keyring-daemon instead of vice versa, so that people who installed the gpg-agent really gets it instead of the GNOME default, or 4) something else. I don t have a strong opinion on how to solve this, but 3) sounds like a simple way forward.
| Publisher: | Princeton University |
| Copyright: | 1998, 2007 |
| Printing: | 2010 |
| ISBN: | 0-691-14600-4 |
| Format: | Trade paperback |
| Pages: | 259 |
Time for another update on my work
for UEFI
improvements in Jessie!
I've got an i386-only UEFI netinst up and running right now, which
will boot and install on the Asus X205TA machine I have. I've got the
required i2c modules included in this build so that the installer can
use the keyboard and trackpad on the machine - useful...!
See #772578 for more
details about
that. Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload1/
to download and test the image. There are a few other missing pieces
of hardware support for this machine yet, but the basics are
there. See
the wiki
for more information.
My initial i386 test CD is not yet going to do an
amd64 installation for you, but it should let you get going with
Debian on these machines! I'm going to continue working on that 32-64
support next.
WARNING: this CD is provided for testing
only. Use at your own risk! If you try this on an
early Intel-based Mac, it will not work. Otherwise,
this should likely work for most folks using 32-bit x86 hardware just
like any other Debian Jessie daily netinst build.
If you have appropriate (U)EFI hardware, please try this image and
let me know how you get on, via the debian-cd and debian-boot mailing
lists.
audio_output
type "pulse"
name "MPD stream"
#server "remote_server" # optional
sink "rtp" # optional
mixer_type "software"
load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties="device.description='RTP Multicast Sink'"
load-module module-rtp-send source=rtp.monitor
load-module module-rtp-recv
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;x.x.x.x
set-card-profile 0 output:iec958-stereo+input:analog-stereo
realtime-scheduling = yes
realtime-priority = 5
resample-method = src-sinc-fastest
default-sample-rate = 44100
default-fragments = 4
default-fragment-size-msec=20
load-module module-alsa-card device_id=0 tsched=0 fragments=10 fragment_size=640 tsched_buffer_size=4194384 tsched_buffer_watermark=262144
mplayer -really-quiet -cache 64 -cache-min 95 -demuxer rawaudio -rawaudio format=0x20776172 rtp://224.0.0.56:46510
squeezelite -a 200:10 -o dmix -u hLX -z
squeezelite -a 800:10:16:0 -n kitchen -z
I just watched a CCC
talk
in which the speaker claims Perl is horribly broken. Watching it was
fairly annoying however, since I had to restrain myself from throwing
things at the screen.
If you're going to complain about the language, better make sure you
actually understand the language first. I won't deny that there are a
few weird constructions in there, but hey. The talk boils down to a
claim that perl is horrible, because the list "data type" is "broken".
First of all, Netanel, in Perl, lists are not arrays. Yes, that's
confusing if you haven't done more than a few hours of Perl, but hear me
out. In Perl, a list is an enumeration of values. A variable with an '@'
sigil is an array; a construct consisting of an opening bracket ('(')
followed by a number of comma- or arrow-separated values (',' or '=>'),
followed by a closing bracket, is a list. Whenever you assign more than
one value to an array or a hash, you need to use a list to enumerate the
values. Subroutines in perl also use lists as arguments or return
values. Yes, that last bit may have been a mistake.
Perl has a concept of "scalar context" and "list context". A scalar
context is what a sub is in when you assign the return value of your sub
to a scalar; a list context is when you assign the return value of your
sub to an array or a hash, or when you use the list construct (the
thing with brackets and commas) with sub calls (instead of
hardcoded values or variables) as the individual values. This works as
follows:
sub magic
if (wantarray())
print "You're asking for a list!";
return ('a', 'b', 'c');
else
print "You're asking for a scalar!";
return 'a';
print ("list: ", magic(), "\n");
print "scalar: " . magic() . "\n";
You're asking for a list!
list: abc
You're asking for a scalar!
scalar: a
print line creates a list (because things
are separated by commas); the second one does not (the '.' is perl's
string concatenation operator; as you can only concatenate scalars, the
result is that you call the magic() sub in scalar context).
Yes, seen as how arrays are not lists, the name of the wantarray()
sub is horribly chosen. Anyway.
It is documented that lists cannot be nested. Lists can only be
one-dimensional constructs. If you create a list, and add another list
as an element (or something that can be converted to a list, like an
array or a hash), then the result is that you get a flattened list. If
you don't want a flattened list, you need to use a reference instead.
A reference is a scalar value that, very much like a pointer in C,
contains a reference to another variable. This other variable can be an
array, a hash, or a scalar. But it cannot be a list, because it must be
a variable -- and lists cannot be variables.
If you need to create multi-dimensional constructs, you need to use
references. Taking a reference is done by prepending a backslash to
whatever it is you're trying to take a reference of; or, in the case of
arrays of hashes, one can create an anonymous array or hash with [] resp
. E.g., if you want to add a non-flattened array to a list, you
instead create a reference to an array, like so:
$arrayref = [ 'this', 'is', 'an', 'anonymous', 'array'];
@multiarray = ('elem1', $arrayref);
@multiarray = ('elem1', [ 'this', 'is', 'an', 'anonymous', 'array']);
@onedimarray = ('this', 'is', 'not', 'an', 'anonymous', 'array');
@multiarray = ('elem1', \@onedimarray);
%hash = 'a' => 'b' ;
@array = [ '1', '2' ];
%hash will result in an (unusable) hash with a single
key that is a reference to an anonymous hash (which cannot be accessed
anymore) and a value of undef; the assignment to @array will result
in a two-dimensional array with one element in the first dimension, and
two elements in the second.
The CGI.pm fix which Natanel dismisses in the Q&A part of the talk as a
"warning" which won't help (because it would be too late) is actually
a proper fix, which should warn people in all cases. That is, if you do
this:
%hash = 'name' => $name, 'password' => $cgi->param('password') ;
param() sub will notice that it's being called in list
context, and issue a warning -- regardless of whether the user is
passing one or two password query-parameters. It uses the wantarray()
sub, and produces a warning if that returns true.
In short, Perl is not the horribly broken construct that Natanel claims
it to be. Yes, there are a few surprises (most of which exist for
historical reasons), and yes, those should be fixed. This is why the
Perl community has redone much of perl for Perl 6. But the fact that
there are a few surprises doesn't mean the whole language is broken.
There are surprises in most languages; that is a fact of life.
Yes, the difference between arrays and hashes on the one hand, and
lists on the other hand, is fairly confusing; it took me a while to
understand this. But once you get the hang of it, it's not all that
difficult. And then these two issues that Natanel found (which I suppose
could be described as bugs in the core modules) aren't all that
surprising anymore.
So, in short:
Gammu 1.34.0 has been just released. It has been more than year from last Gammu release and it's time to release all new features and bugfixes.
Full list of changes:
Filed under: English Gammu Wammu 0 comments Flattr this!
A bit of news on the development of OpenTAC the Open Hardware Test Automation Controller. I ve talked about this at the MiniDebConf 2014 in Cambridge. (Video available). The development is being tracked on the Vero-Apparatus wiki and as this is Open Hardware, the files are attached to the wiki (All files are CC BY-SA 4.0).
Andy completed the schematics at the start of November, allowing work to start on the routing. With routing completed, orders were placed for manufacture of the first PCBs on the 19th December 2014. Whilst waiting for the PCBs to arrive we re working on the device tree database (my first real experience with creating a device tree) which will underpin the PDU and serial console services available to the user as well as the admin interface for control of the USB subsystems, fan control, power control and thermal monitoring. The first thing we need to do is create a data dictionary a table to correlate software identifiers with the real hardware pins. We ll then follow that through with a default device tree overlay that will leave all the associated I/O lines in a safe initial state.
Once we have some code, I ll be pushing to a branch on GitHub. We ve also got an internal git repo on vero-apparatus for OpenTAC files which we will add to in due course.
Image of the board as rendered prior to prototype production:
More to come once we have the hardware on the desk
It seems that the 0.37 release was not that good as I hoped for, so here comes another bugfix release. So here comes Wammu 0.38.
The list of changes is not really huge:
Filed under: English Gammu Wammu 0 comments Flattr this!
Next.