Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 1
The example Roger Leigh posted above, for libtiff, is compelling. If you read it, you'll see it is a 1:1 mapping to what autoconf does, and it's a lot neater and more maintainable.
Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 1
Cmake are scons require that they already be installed.
This is assuming that a shell capable of running./configure is available on all of your platforms.
Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 1
I should correct that: automake builds things by creating makefiles. The configure script created by autoconf is concerned with configuration rather than building, but its output is input to automake.
Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 1
CMake, Scons, etc. are mainly targeted at dependency-based building of programs. Autotools doesn't really build anything. It goes through a long list of system facilities, determining if each is present. For many, perhaps most of them, it builds a little C program that exercises the facility, and sees if it compiles.
Now, there's another poster who says you really can do this with CMake, which I'll have to look at.
Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 4, Insightful
This isn't really a problem for StackOverflow. It's a problem for the developers of GCC and its libraries, and a policy problem for the overall GNU project in that Autotools is IMO too much of a mess to live, and is a barrier to participation as it stands. That's why I talk about it here instead of just submitting it as a bug report.
I would like to see someone come up with an alternative. That alternative is not CMake or Scons, etc., because those are build systems rather than systems that probe a platform for fine differences in the programming environment and produce a set of macro switches as output.
Yes, I can get a pre-built toolchain or a building kit, but it doesn't really solve the problem of not being able to build the current GCC with the right settings in its configure script and to use it with the right C library and kernel headers for my device. Should I modify any of those toolchain kits to do that, they'll come up with the same errors.
Re:Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 3
Besides devKitARM, there is the collection of toolchains mentioned here. I am getting most of my clues from the Emcraft toolchain, which is the only one for the SmartFusion. And we're great friends with Emcraft, but I want something a bit newer and a different build-tree style.
My last approach to the libstdc++ mailing list, here, was left unanswered. I figured out the problem behind that one, but it would have been nice to get some advice.
Autoconf doesn't have a --synclines flag, but I might be able to pass it in the M4 environment variable. I'll give it a try.
autotools is no fun
on
GCC 5.2 Released
·
· Score: 5, Insightful
I've been configuring a toolchain for Algoram's programmable radio transceiver, which has a SmartFusion 2 containing a Cortex M3. Until today, I've been working with GCC 5.1. Building GCC for cross-compilation on a no-MMU, no-FP processor and a software platform that doesn't support shared libraries isn't trivial, though it should be. GCC has many configure scripts, one for each library that it builds and at least one for the compiler. You run across many configure issues which are difficult to debug. For example, the configure file, a macro-expanded shell script, doesn't have source code line numbers from its configure.ac file. Error messages do not in general indicate the actual problem, and are difficult to trace. Figuring out what to fix is far from trivial. I ended up not being able to use multilibs (which would have allowed me to build for FP processors like Cortex M4F as well), couldn't link in ISL, couldn't build libjava.
Some of these are beginner problems - I'm new to building cross-toolchains and have avoided autotools as much as possible before this project. But not all of them.
One would think that we could build a better system today than such voluminous M4 and shell. Perhaps basing it on a test framework might be the right approach.
First of all, this is really old news. SpaceShip One no longer flies and has been a museum piece for years, and Virgin's burned their bridges with Scaled Composites and thus made it a lot less likely that they will be able to mount a near space effort with the SpaceShip Two design.
Second, this is not an orbital re-entry system, because it's not well-suited for a heat shield and thus can't do the necessary atmospheric braking. It's just a system to get you back from high altitude suborbital flights.
You make a good emotional appeal, but the reality is that someone just casually sharing a song isn't likely to be subject to these penalties at all.
That's sort of like saying the penalty against burglary would only be used against someone who steals the Crown Jewels.
If the law specifies a minimum offense at all, you can be sure that anyone reaching that minimum is at risk. We've had very many documented civil copyright trolls going after otherwise un-notable individuals, and thus abuse of criminal law is certain.
It would have to be many farads, this isn't a car stereo. The problem is how to gate the power after such a large capacitor. You're right that it could increase the momentary current. But that's also the problem. Their "contactor", a mechanical switch, has had to be upgraded with exotic alloy to deal with heating. And if you try to gate the power before it, you end up feeding what is very close to a short circuit while it charges.
This is a fun device that can show you what can be done with 3D printed plastic. That said, it's useless. It would be really cool if I could apply 1 pound of force to the crank, turn it a Million times, and have it apply a Million pounds of rotational force at the other end. But it's made of plastic, so it won't do that. Indeed, the fast-rotating parts would wear out before the slow-rotating part made a single turn. So it's not even good as a kind of clock.
All that said, it's a good conversation piece, and probably worth the price for that.
I currently have a web radio transceiver front panel application that works on Linux, Windows, MacOS, Android, Amazon Kindle Fire, under Chrome, Firefox, or Opera. No porting, no software installation. See blog.algoram.com for details of what I'm writing.
The one unsupported popular platform? iOS, because Safari doesn't have the function used to acquire the microphone in the web audio API (and perhaps doesn't have other parts of that API), and Apple insists on handicapping other browsers by forcing them to use Apple's rendering engine.
I don't have any answer other than "don't buy iOS until they fix it".
Super Dracos are for escape in flight too, including in and past MaxQ. But they are on Crew Dragon, not Cargo Dragon. Cargo Dragon did not carry a crew and wasn't programmed to save itself.
Most of us do have a need to transmit messages privately. Do you not make any online purchases?
Yes, but those have to use public-key encryption. I am sure of my one-time-pad encryption because it's just exclusive-OR with the data, and I am sure that my diode noise is really random and there is no way for anyone else to predict or duplicate it. I can not extend the same degree of surety to public-key encryption. The software is complex, the math is hard to understand, and it all depends on the assumption that some algorithms are difficult to reverse - which might not be true.
Most algorithms to do this use the time between keypresses, measured to very high precision so that the lower bits are chaotic. So it doesn't really matter what keys you hit, and it doesn't matter how rythmic your typing is.
The problem with FM static is that you could start receiving a station, and if you don't happen to realize you are now getting low-entropy data, that's a problem.
There are many well-characterized forms of electronic noise: thermal noise, shot noise, avalanche noise, flicker noise, all of these are easy to produce with parts that cost a few dollars.
True randomness comes from quantum mechanical phenomena. Linux/dev/random is chaotic, yes, enough to seed a software "R"NG. But we can do better and devices to do so are cheap these days.
I wouldn't trust anything but diode noise for randomness. If I had a need to transmit messages privately, I'd only trust a one-time pad.
Communism has been tried on a large scale - see Mao's Great Leap Forward.
Nope. That was a totalitarian socialist program pushing a collectivism that didn't work. Communism is a post-scarcity society and obviously scarcity was the thing Mao produced best.
I didn't actually work on GPUs very much at Pixar, the image computer I worked on was the grandfather of the SIMD image processing instructions on modern CPUs. What would become a GPU later on was a very expensive box from Silicon Graphics, I had one that cost at least a quarter Million dollars.
If they actually told us how to program their microengines, something good might come of it. But they'll probably just BSD-license a list of numbers, as others have.
I liked writing bit-slice microcode at Pixar. I really could get every last bit of power out of the hardware.
Maybe you should learn what communism is before calling anyone "commiefriend". (Which I have to say, is really repulsive. It's sort of like picking your nose over the internet.) I think you are discussing the difference between lasiez-faire ecomomics and regulated markets. Communism is a very great difference in scale from that. And it's never been tried on a national scale just as "free market" has never been tried because there are always economic biases that make it impossible. What there has been so far is socialism.
I think you're missing the fundamental economic issue that drives all of this. It's the provision of essentially infinite amounts of credit. This is done by government, not banks. Essentially all home loans come from Fannie Mae or Freddie Mac, banks and finance companies are really just front-ends for them and sell their loans to the government once financed.
Given infinite credit, any scarce but necessary resource is going to be bid to absurd values.
It is by no means being a hippie to assert that government should not distort the market for credit, and to expect that urban and suburban land values would return to more realistic rates once the distortion was removed. Too bad that lots of people have already invested in unrealistic land values. They would have to lose.
Superconductors just exclude magnetic flux. I am not getting how it matters what produces the magnetic flux - be it ferromagnetic or electromagnetic. My only Meissner effect demo used a permanent magnet.
Slashdot Mirror
The example Roger Leigh posted above, for libtiff, is compelling. If you read it, you'll see it is a 1:1 mapping to what autoconf does, and it's a lot neater and more maintainable.
This is assuming that a shell capable of running ./configure is available on all of your platforms.
I should correct that: automake builds things by creating makefiles. The configure script created by autoconf is concerned with configuration rather than building, but its output is input to automake.
CMake, Scons, etc. are mainly targeted at dependency-based building of programs. Autotools doesn't really build anything. It goes through a long list of system facilities, determining if each is present. For many, perhaps most of them, it builds a little C program that exercises the facility, and sees if it compiles.
Now, there's another poster who says you really can do this with CMake, which I'll have to look at.
This isn't really a problem for StackOverflow. It's a problem for the developers of GCC and its libraries, and a policy problem for the overall GNU project in that Autotools is IMO too much of a mess to live, and is a barrier to participation as it stands. That's why I talk about it here instead of just submitting it as a bug report.
I would like to see someone come up with an alternative. That alternative is not CMake or Scons, etc., because those are build systems rather than systems that probe a platform for fine differences in the programming environment and produce a set of macro switches as output.
Yes, I can get a pre-built toolchain or a building kit, but it doesn't really solve the problem of not being able to build the current GCC with the right settings in its configure script and to use it with the right C library and kernel headers for my device. Should I modify any of those toolchain kits to do that, they'll come up with the same errors.
Besides devKitARM, there is the collection of toolchains mentioned here. I am getting most of my clues from the Emcraft toolchain, which is the only one for the SmartFusion. And we're great friends with Emcraft, but I want something a bit newer and a different build-tree style.
My last approach to the libstdc++ mailing list, here, was left unanswered. I figured out the problem behind that one, but it would have been nice to get some advice.
Autoconf doesn't have a --synclines flag, but I might be able to pass it in the M4 environment variable. I'll give it a try.
I've been configuring a toolchain for Algoram's programmable radio transceiver, which has a SmartFusion 2 containing a Cortex M3. Until today, I've been working with GCC 5.1. Building GCC for cross-compilation on a no-MMU, no-FP processor and a software platform that doesn't support shared libraries isn't trivial, though it should be. GCC has many configure scripts, one for each library that it builds and at least one for the compiler. You run across many configure issues which are difficult to debug. For example, the configure file, a macro-expanded shell script, doesn't have source code line numbers from its configure.ac file. Error messages do not in general indicate the actual problem, and are difficult to trace. Figuring out what to fix is far from trivial. I ended up not being able to use multilibs (which would have allowed me to build for FP processors like Cortex M4F as well), couldn't link in ISL, couldn't build libjava.
Some of these are beginner problems - I'm new to building cross-toolchains and have avoided autotools as much as possible before this project. But not all of them.
One would think that we could build a better system today than such voluminous M4 and shell. Perhaps basing it on a test framework might be the right approach.
First of all, this is really old news. SpaceShip One no longer flies and has been a museum piece for years, and Virgin's burned their bridges with Scaled Composites and thus made it a lot less likely that they will be able to mount a near space effort with the SpaceShip Two design.
Second, this is not an orbital re-entry system, because it's not well-suited for a heat shield and thus can't do the necessary atmospheric braking. It's just a system to get you back from high altitude suborbital flights.
That's sort of like saying the penalty against burglary would only be used against someone who steals the Crown Jewels.
If the law specifies a minimum offense at all, you can be sure that anyone reaching that minimum is at risk. We've had very many documented civil copyright trolls going after otherwise un-notable individuals, and thus abuse of criminal law is certain.
It would have to be many farads, this isn't a car stereo. The problem is how to gate the power after such a large capacitor. You're right that it could increase the momentary current. But that's also the problem. Their "contactor", a mechanical switch, has had to be upgraded with exotic alloy to deal with heating. And if you try to gate the power before it, you end up feeding what is very close to a short circuit while it charges.
This is a fun device that can show you what can be done with 3D printed plastic. That said, it's useless. It would be really cool if I could apply 1 pound of force to the crank, turn it a Million times, and have it apply a Million pounds of rotational force at the other end. But it's made of plastic, so it won't do that. Indeed, the fast-rotating parts would wear out before the slow-rotating part made a single turn. So it's not even good as a kind of clock.
All that said, it's a good conversation piece, and probably worth the price for that.
I currently have a web radio transceiver front panel application that works on Linux, Windows, MacOS, Android, Amazon Kindle Fire, under Chrome, Firefox, or Opera. No porting, no software installation. See blog.algoram.com for details of what I'm writing.
The one unsupported popular platform? iOS, because Safari doesn't have the function used to acquire the microphone in the web audio API (and perhaps doesn't have other parts of that API), and Apple insists on handicapping other browsers by forcing them to use Apple's rendering engine.
I don't have any answer other than "don't buy iOS until they fix it".
Super Dracos are for escape in flight too, including in and past MaxQ. But they are on Crew Dragon, not Cargo Dragon. Cargo Dragon did not carry a crew and wasn't programmed to save itself.
Yes, but those have to use public-key encryption. I am sure of my one-time-pad encryption because it's just exclusive-OR with the data, and I am sure that my diode noise is really random and there is no way for anyone else to predict or duplicate it. I can not extend the same degree of surety to public-key encryption. The software is complex, the math is hard to understand, and it all depends on the assumption that some algorithms are difficult to reverse - which might not be true.
Most algorithms to do this use the time between keypresses, measured to very high precision so that the lower bits are chaotic. So it doesn't really matter what keys you hit, and it doesn't matter how rythmic your typing is.
The problem with FM static is that you could start receiving a station, and if you don't happen to realize you are now getting low-entropy data, that's a problem.
There are many well-characterized forms of electronic noise: thermal noise, shot noise, avalanche noise, flicker noise, all of these are easy to produce with parts that cost a few dollars.
True randomness comes from quantum mechanical phenomena. Linux /dev/random is chaotic, yes, enough to seed a software "R"NG. But we can do better and devices to do so are cheap these days.
I wouldn't trust anything but diode noise for randomness. If I had a need to transmit messages privately, I'd only trust a one-time pad.
Nope. That was a totalitarian socialist program pushing a collectivism that didn't work. Communism is a post-scarcity society and obviously scarcity was the thing Mao produced best.
Whatever it has been used for subsequently, A113 is a classroom at Cal Arts.
I didn't actually work on GPUs very much at Pixar, the image computer I worked on was the grandfather of the SIMD image processing instructions on modern CPUs. What would become a GPU later on was a very expensive box from Silicon Graphics, I had one that cost at least a quarter Million dollars.
If they actually told us how to program their microengines, something good might come of it. But they'll probably just BSD-license a list of numbers, as others have.
I liked writing bit-slice microcode at Pixar. I really could get every last bit of power out of the hardware.
Maybe you should learn what communism is before calling anyone "commiefriend". (Which I have to say, is really repulsive. It's sort of like picking your nose over the internet.) I think you are discussing the difference between lasiez-faire ecomomics and regulated markets. Communism is a very great difference in scale from that. And it's never been tried on a national scale just as "free market" has never been tried because there are always economic biases that make it impossible. What there has been so far is socialism.
I think you're missing the fundamental economic issue that drives all of this. It's the provision of essentially infinite amounts of credit. This is done by government, not banks. Essentially all home loans come from Fannie Mae or Freddie Mac, banks and finance companies are really just front-ends for them and sell their loans to the government once financed.
Given infinite credit, any scarce but necessary resource is going to be bid to absurd values.
It is by no means being a hippie to assert that government should not distort the market for credit, and to expect that urban and suburban land values would return to more realistic rates once the distortion was removed. Too bad that lots of people have already invested in unrealistic land values. They would have to lose.
Superconductors just exclude magnetic flux. I am not getting how it matters what produces the magnetic flux - be it ferromagnetic or electromagnetic. My only Meissner effect demo used a permanent magnet.