Arduino thermometer
Jul. 16th, 2019 07:52 pmNow, the sensible way to find out is to go and buy a thermometer. But Robert Days are closed for the evening. So instead I dug out an Arduino kit I was given for my birthday (Elegoo's "The Most Complete Starter Kit for the Mega 2560") and set to work...

The answer: 27°C!
( Code! )
Submanifolds of a Hilbert Space
Nov. 14th, 2017 11:41 pmWell, it turns out it's all very simple after all, as this image that dropped into my work inbox reveals:

You could tell the email's progress around the office by when different people burst out laughing.
More cross-compiling adventures
Feb. 9th, 2017 09:04 pmNo, this isn't the NAS I was poking at a few years back - that I solved by getting a slightly newer NAS with a more complete Linux install including compiler. Today's target embedded system is a 3DS, using the devkitARM toolchain.
Anyway the answer was surprisingly easy but not at all intuitive: in the project properties go to C++ Build and on the Builder Settings tab tick Generate Makefiles automatically but don't apply the change yet. Then go to C++ Build → Settings and a new Tool Settings tab will be visible. Select Cross Settings and fill in the correct path and prefix (including the trailing hyphen, so something like "arm-none-eabi-"). Finally go back to Builder Settings and untick Generate Makefiles automatically, and now you can apply the changes. Right-click on the project, pick Index → Rebuild and all the broken includes should sort themselves out.
That solved most of my problems but still left Eclipse whining about some unresolved includes. That turned out to be because the code I was looking at wanted a newer C++ standard - to fix that go through the rigmarole to make Tool Settings reappear and under Cross G++ Compiler → Dialect pick the appropriate standard. Or if the one you want isn't listed, then enter the option in Other dialect flags (for devkitARM I needed "-std=c++14").
I still had to manually add the header path for libctru and a couple of defines that were in the Makefile, but that's fair enough - it's getting the system headers all sorted that's the hard part!
(no subject)
Oct. 28th, 2016 08:50 pmIt's most annoying, as RSSOwl minimises to the tray but hides its icon when you reopen it triggering this bug. And some quirk of how the icons have ended up in the tray means it's often the icon for Semagic that vanishes from my taskbar.
Anyway, the workaround is to not use the NIS_HIDDEN flag but instead just add/delete the icon. Or if there's just one application causing it then I think moving it to the bottom-right corner of the tray also solves this, as stuff in the last row seems to be reordered correctly.
I wonder how one goes about reporting bugs to Microsoft?
Semagic bugfixing: XMPlay music detection
Oct. 8th, 2016 09:11 pm( Semagic bugfixing: XMPlay music detection )
Compiling Semagic
Oct. 7th, 2016 11:40 pm( This was surprisingly successful )
Slightly improved file uploader
Nov. 20th, 2014 08:55 pm( PHP! )
The change is only a few lines - the call to move_uploaded_file has been replaced with
$pathinfo = pathinfo($_FILES['file']['name'][$i]); $dest = $pathinfo['filename'] . strftime('-%Y%m%d-%H%M%S.') . $pathinfo['extension']; move_uploaded_file($_FILES['file']['tmp_name'][$i], $dest);
The result is each uploaded file has the current date and time appended to it (for example, vorpal.jpeg becomes vorpal-20141120-205045.jpeg). Obviously this will still overwrite files if you manage to upload the same filename multiple times within the same second, to which my answer is meh! As before, feel free to use it under the 3-clause BSD license.
Eclipse is a maze of twisty build dependencies, all different. As best as I can tell there's the following:
- Build path: this affects compiling and possibly running your project. Split into separate widgets for dependent projects and for libraries/jars.
- Order and export: the same widget handles both the build order and "exporting" stuff to dependent projects, which may or may not actually achieve anything. Certainly the export option doesn't affect what appears in your .WAR.
- Deployment assembly: this doesn't affect your build path, but instead controls what ends up in your .WAR should you generate one. This is also present in non-web projects and mostly works, except not all items are propagated to the web projects (e.g. if A is a web project and B and C are normal Java projects with a dependency A -> B -> C, the dependency from B to C isn't picked up by A. So A needs to explicitly require projects B and C even though it doesn't directly use C). Oh, and if you have a web project then I lied and any direct dependencies here are actually included in your build path.
- Project references: the Java toolchain completely ignores this and makes no attempt to keep it synchronised with the other dependencies. Which is a shame, as the Eclipse interface uses this to work out which projects depend on other projects.
It all seems massively overcomplicated when what's really needed is a way to list libraries/projects and mark them as either "build-time", "run-time", or both. Then when compiling it uses just the items listed as build-time, and when running or creating .WARs it uses everything listed as run-time and includes transitive run-time dependencies as well.
A true gentleman leaves no puzzle unsolved
Nov. 7th, 2011 10:32 pmOkay, so it turns out that talismancer's post yesterday was filler. The moral balance has swung back!
As tempting as it is to fulfill the entirety of NaBloPoMo with us commenting on each other's posts, I feel like I should actually write something. So in the interests of increasing audience participation, I shall set a Java puzzler.
The puzzler consists of the following class:
import java.util.ArrayList; public class Foo { private ArrayList<Object> barList = new ArrayList<Object>(); public void fillBarList() { for (int i = 0; i < 10; i++) { Object o = new Object(); System.out.println("Adding " + o + " at index " + i); barList.add(o); } } public void emptyBarList() { for (Object o : barList) { System.out.println("Removing " + o); barList.remove(o); } } public static void main(String[] args) { Foo f = new Foo(); f.fillBarList(); f.emptyBarList(); } }
Without running it (because that would be cheating and you will be mocked for it), what do you think will happen when Foo.main() is called?
The shiny new LJ Stat-o-matic
Nov. 6th, 2011 11:26 pmSo, after 2 hours of writing some truely horrid Java code, I now have some shiny new comment stats from my shiny new LJ Stat-o-matic!
Top commenters on
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
1 | ![]() | ![]() ![]() ![]() |
2 | ![]() | ![]() ![]() ![]() |
3 | ![]() | ![]() ![]() ![]() |
4 | ![]() | ![]() ![]() ![]() |
5 | ![]() | ![]() ![]() ![]() |
6 | ![]() | ![]() ![]() ![]() |
7 | ![]() | ![]() ![]() ![]() |
8 | ![]() | ![]() ![]() ![]() |
9 | Anonymous | ![]() ![]() ![]() |
10 | ![]() | ![]() ![]() ![]() |
Total Commenters: 79
Total Comments: 1676 (not including 148 deleted and 3 screened)
Report generated Sun Nov 06 23:14:41 GMT 2011 by boggyb's LJ Stat-o-matic 1.0 (inspired by
scrapdog's LJ Comment Wizard)
Credit where credit's due: scrapdog's original LJ Comment wizard is the inspiration for the tool and the result formatting, although I've ended up with a different calculation for the bars (his looks logarithmic, but I couldn't be bothered to do that and just made mine linear).
The other major difference with my stats is that I've excluded deleted and screened comments from the results. This has demoted Anonymous to #9 and restored olego to his rightful place at #2.
Source code is available if you want to run it yourself, but be warned - as said above, it was thrown together rather quickly over a couple of hours and doesn't contain a single comment!
Java puzzle
Jan. 27th, 2011 11:23 pmSomething a colleague came up with at work the other day...
Consider the following Java classes:
public class FooBase {}; public class Foo extends FooBase {}; public class Bar { public Bar(FooBase) { System.out.println("Constructor Bar(FooBase) called"); } public Bar(Foo f) { System.out.println("Constructor Bar(Foo) called"); } } public class Test { public static void testSomething() { java.util.ArrayList<FooBase> list = new ArrayList<FooBase>(); list.add(new Foo()); FooBase item = list.get(0); Bar b = new Bar(item); } }
Without compiling and running the program (because that would be too easy a way to solve this), what do you think will happen when you call Test.testSomething()?
My guess is that it will print "Constructor Bar(Foo) called", because while item is a reference of type FooBase the object being pointed to by item is actually of type Foo. But then the guy who came up with this pointed out that the output "Constructor Bar(FooBase) called" would also make sense, and if this were C++ that would be the expected output. The difference is all C++ knows is that it has a pointer to something that must be a FooBase, while Java knows that it has a pointer to something that is actually a Foo.
More gdb fail
Sep. 14th, 2009 09:22 pm(gdb) watch function::variable if function::variable == 0xff
(gdb) run
This set of commands, again in a fresh gdb instance, works:
(gdb) info address variable
(gdb) info address function::variable
(gdb) whatis variable
(gdb) whatis function::variable
(gdb) watch function::variable if function::variable == 0xff
(gdb) run
Discuss.
Today I attempted to debug a test program that segfaults about 5 minutes after startup for no apparent reason. I managed to get a core dump of it, and loaded it into gdb in the hope of finding what was going on. Hahaha.
gdb could give me a valid stack trace showing the error, and could disassemble the program around the error to show me the actual instructions involved. However, gdb could not tell me the value of all the variables there (it claimed that some variables weren't even defined, nevermind that the program uses them all over the place!), nor could it actually match the disassembly up to the source.
Come on, folks, Visual C++ has been able to do this for decades! The Windows debugging tools are so far ahead it's embarassing for Linux.
I did actually discover a patch to gdb to achieve this, submitted April last year. Unfortuantly it's not in the latest released version of gdb (released March last year), and I really don't fancy building gdb from source myself.
(no subject)
Sep. 9th, 2009 09:29 pmAt which point it stops truncating the string and sends the full text all the way through the system. Ah-hah, I think, this must be a heisenbug (adding debugging code can have very subtle effects on program behaviour). I'll remove my debug node from the flowchart, rejoin the original pair of nodes together, and upload the chart.
And it's still working. Ok, I think, the act of converting the chart for the unit must have changed it slightly from the original. It shouldn't do so as that implies non-deterministic code somewhere, but that'd at least explain what's going on. So I dug out the original already-converted chart and transfer that, thinking that this'll now restore the broken behaviour (when debugging it's always helpful to be able to reproduce the original bug - if you can reliably reproduce it, you can use a debugger to see every step involved and often quickly spot the actual problem).
Except it's still working!
My coding Muse
Oct. 6th, 2006 11:08 pmNow I just need to turn my fingers to the other programs I've been meaning for a while to code. That or actually release something - a trawl through my code folder showed about half-a-dozen programs at release quality, an ancient attempt at writing a Pokémon clone, various unfinished programs ranging from an empty file to a complete UI skeleton, and some stuff that I don't remember writing. Oh, and one program that I think I wrote, but am not actually sure. It has my style, but I can't remember ever writing it.
You know you've been programming too long when you can't remember why you wrote something.
(no subject)
Mar. 26th, 2006 12:06 amOf all the fun things to encounter with Visual Basic 6:
"Unexpected error occured in code generator or linker. --View error messages?" Yes/No/Help
*Yes*
( Wide error message )I didn't think it was possible to generate an internal compiler error in VB.
Edit: okay, I think I've worked out what line is killing it. Unfortuantly, this line of code basically reads "MyControl.Data = GiganticVariableSizeByteArray", and is a rather critical line for that control to work. I may have to abandon that idea of mine. The compiler appears to dislike moving large byte arrays around.
(no subject)
Mar. 25th, 2006 02:40 amThat's not stopping me attempting to decompress S3TC with it, or convert between big and little endian, or generally do horrible bit manipulation. All hail user-defined types, and the mighty LSet operator!