Forum comments in chronological order
Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.
Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.
- Jun 2007
- Aug 2007
- Oct 2007
- Nov 2007
- Dec 2007
- Jan 2008
- Feb 2008
- Mar 2008
- Apr 2008
- May 2008
- Jun 2008
- Jul 2008
- Aug 2008
- Sep 2008
- Oct 2008
- Nov 2008
- Dec 2008
- Jan 2009
- Feb 2009
- Mar 2009
- Apr 2009
- May 2009
- Jun 2009
- Jul 2009
- Aug 2009
- Sep 2009
- Oct 2009
- Nov 2009
- Dec 2009
- Jan 2010
- Feb 2010
- Mar 2010
- Apr 2010
- May 2010
- Jun 2010
- Jul 2010
- Aug 2010
- Sep 2010
- Oct 2010
- Nov 2010
- Dec 2010
- Jan 2011
- Feb 2011
- Mar 2011
- Apr 2011
- May 2011
- Jun 2011
- Jul 2011
- Aug 2011
- Sep 2011
- Oct 2011
- Nov 2011
- Dec 2011
- Jan 2012
- Feb 2012
- Mar 2012
- Apr 2012
- May 2012
- Jun 2012
- Jul 2012
- Aug 2012
- Sep 2012
- Oct 2012
- Nov 2012
- Dec 2012
- Jan 2013
- Feb 2013
- Mar 2013
- Apr 2013
- May 2013
- Jun 2013
- Jul 2013
- Aug 2013
- Sep 2013
- Oct 2013
- Nov 2013
- Dec 2013
- Jan 2014
- Feb 2014
- Mar 2014
- Apr 2014
- May 2014
- Jun 2014
- Jul 2014
- Aug 2014
- Sep 2014
- Oct 2014
- Nov 2014
- Dec 2014
- Jan 2015
- Feb 2015
- Mar 2015
- Apr 2015
- May 2015
- Jun 2015
- Jul 2015
- Aug 2015
- Sep 2015
- Oct 2015
- Nov 2015
- Dec 2015
- Jan 2016
- Feb 2016
- Mar 2016
- Apr 2016
- May 2016
- Jun 2016
- Jul 2016
- Aug 2016
- Sep 2016
- Oct 2016
- Nov 2016
- Dec 2016
- Jan 2017
- Feb 2017
- Mar 2017
- Apr 2017
- May 2017
- Jun 2017
- Jul 2017
- Aug 2017
- Sep 2017
- Oct 2017
- Nov 2017
- Dec 2017
- Jan 2018
- Feb 2018
- Mar 2018
- Apr 2018
- May 2018
- Jun 2018
- Jul 2018
- Aug 2018
- Sep 2018
- Oct 2018
- Nov 2018
- Dec 2018
- Jan 2019
- Feb 2019
- Mar 2019
- Apr 2019
- May 2019
- Jun 2019
- Jul 2019
- Aug 2019
- Sep 2019
- Oct 2019
- Nov 2019
- Dec 2019
- Jan 2020
- Feb 2020
- Mar 2020
- Apr 2020
- May 2020
- Jun 2020
- Jul 2020
- Aug 2020
- Sep 2020
- Oct 2020
- Nov 2020
- Dec 2020
- Jan 2021
- Feb 2021
- Mar 2021
- Apr 2021
- May 2021
- Jun 2021
- Jul 2021
- Aug 2021
- Sep 2021
- Oct 2021
- Nov 2021
- Dec 2021
- Jan 2022
- Feb 2022
- Mar 2022
- Apr 2022
- May 2022
- Jun 2022
- Jul 2022
- Aug 2022
- Sep 2022
- Oct 2022
- Nov 2022
- Dec 2022
- Jan 2023
- Feb 2023
- Mar 2023
- Apr 2023
- May 2023
- Jun 2023
- Jul 2023
- Aug 2023
- Sep 2023
- Oct 2023
- Nov 2023
- Dec 2023
- Jan 2024
- Feb 2024
- Mar 2024
- Apr 2024
- May 2024
- Jun 2024
- Jul 2024
- Aug 2024
- Sep 2024
- Oct 2024
May 2013
Anonymous
Sat 4-May-2013 21:16
Sat 4-May-2013 21:16
Fratres,is it based in Passacaglia form?
Anonymous
Sun 5-May-2013 19:46
Sun 5-May-2013 19:46
Interesting essay with some valid points, but the context lacks depth: it is one thing to do this because it is a hobby, quite another if one must walk the very delicate line of writing code easy to debug in consideration of others, because one is an entrepreneur, racing against the clock. "When are we going to ship?"
You are probably privy to the Zen of "software is done when it is done!", which means that writing quality code must necessarily avoid cleverness in favor of maintainability: if one is an entrepreneur, one must eventually ship, or the startup will bust.
Rule of clarity: clarity is better than cleverness
"Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself)."
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877610
Rule of representation: fold knowledge into data, so program logic can be stupid and robust
"Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic."
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2878263
You are probably privy to the Zen of "software is done when it is done!", which means that writing quality code must necessarily avoid cleverness in favor of maintainability: if one is an entrepreneur, one must eventually ship, or the startup will bust.
Rule of clarity: clarity is better than cleverness
"Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself)."
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877610
Rule of representation: fold knowledge into data, so program logic can be stupid and robust
"Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic."
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2878263
Anonymous
Sun 5-May-2013 19:53
Sun 5-May-2013 19:53
I would also like to leave you to think about the following:
anyone can write clever code; anyone can write complex code; anyone can over-complicate...
...but if you are really, really smart, make a complex thing simple! Can you go the other way, can you effectively simplify complex things? That is true smarts, because it is incredibly hard to do, and requires one to be extremely smart, knowledgeable, and experienced. Not very many people can do it, even among the smart.
anyone can write clever code; anyone can write complex code; anyone can over-complicate...
...but if you are really, really smart, make a complex thing simple! Can you go the other way, can you effectively simplify complex things? That is true smarts, because it is incredibly hard to do, and requires one to be extremely smart, knowledgeable, and experienced. Not very many people can do it, even among the smart.
phf
Martin Schulte
Tue 7-May-2013 13:54
Martin Schulte
Tue 7-May-2013 13:54
Great! Do you consider releasing the soundtrack?
Anonymous
Wed 8-May-2013 18:40
Wed 8-May-2013 18:40
Rather than parsing the replay routine and doing all this analysis, would it not have been cheaper to just extract the data, and write one's own replay routine?
I mean, most of the $1000-$1003 tunes were made in a limited set of music programs, were they not? And $1800 tunes, there is only one culprit, Future Composer, whose format should be well understood, well enough to construct one's own relocatable replay routine (if using Future Composer's own relocation capabilities is not desired). That should cover 90% of tunes out there, should it not?
I mean, most of the $1000-$1003 tunes were made in a limited set of music programs, were they not? And $1800 tunes, there is only one culprit, Future Composer, whose format should be well understood, well enough to construct one's own relocatable replay routine (if using Future Composer's own relocation capabilities is not desired). That should cover 90% of tunes out there, should it not?
Anonymous
Wed 8-May-2013 18:44
Wed 8-May-2013 18:44
What C=64 code really needs is support for executable and linking format ("ELF"). Writing ELF headers from Turbo Assembler is no problem, but something should be able to read and parse the global offset table ("GOT"), which is exactly what is needed here for all these SID tunes (not the data itself, of course, but for a truly relocatable replay routine).
So maybe a little "shim" routine which would act as the runtime linker for dynamic objects, ld.so.1?
Hmmm, that might be a cool next project for me to implement, hmmmmm...
So maybe a little "shim" routine which would act as the runtime linker for dynamic objects, ld.so.1?
Hmmm, that might be a cool next project for me to implement, hmmmmm...
Anonymous
Thu 9-May-2013 01:11
Thu 9-May-2013 01:11
Wow, that sounds great!
Anonymous
Sun 12-May-2013 11:33
Sun 12-May-2013 11:33
Greetings from Aus.
The Hardware Chiptune Project is a work of Genuis!
I love your work and your website; I do hope you make other tunes with a similar orchestration in terms of the waveforms used. I hope to build something like this myself when I get the time. You're an inspiration!
The Hardware Chiptune Project is a work of Genuis!
I love your work and your website; I do hope you make other tunes with a similar orchestration in terms of the waveforms used. I hope to build something like this myself when I get the time. You're an inspiration!
Anonymous
Mon 13-May-2013 01:52
Mon 13-May-2013 01:52
The soundtrack is released, in that it's part of the (released) source code (see sfx.c).
A pre-rendered MP3 would indeed be nice, I you meant that. --jn
A pre-rendered MP3 would indeed be nice, I you meant that. --jn
Anonymous
Mon 13-May-2013 12:25
Mon 13-May-2013 12:25
The soundtrack is released, in that it's part of the (released) source code (see sfx.c).
A pre-rendered MP3 would indeed be nice, I you meant that. --jn
A pre-rendered MP3 would indeed be nice, I you meant that. --jn
Yes, that's what I meant. :)
Anonymous
Wed 15-May-2013 23:44
Wed 15-May-2013 23:44
That's awesome work there!
Just wondering, are you going to open up some of the guts of your build?
I would really like to tinker around with it, but am clearly lacking the skills to pull this off :(
Just wondering, are you going to open up some of the guts of your build?
I would really like to tinker around with it, but am clearly lacking the skills to pull this off :(
A case against syntax highlighting
HoltomS
Stephen Holtom
Fri 17-May-2013 11:40
Stephen Holtom
Fri 17-May-2013 11:40
In addition to the points mentioned above, I'd like to point out that some skimming is *good*.
For example, say a string literal is being passed in a function call. In essence, there are two bits of information for a programmer to be aware of:
1. A string literal is being passed
2. The contents of the string
Now, it is *right* that those things can be considered separately. It's right that I can saccade past the contents of the string if right now I'm not interested in that argument, and need to examine another argument to the function more closely.
It is wrong to be forced every time to track my eyes across carefully, and find the closing quote, before I can look at the next argument to the function. These little inefficiencies add up.
The analogy with a novel is false. A novel must be read in a linear fashion. For most modern code paradigms it's not even clear what linear would mean (a source file, a stack trace, an inheritance hierarchy?). Furthermore the English language does not have the same kind of formal syntactic structures as code: function calls, literals, operators, macros etc are not merely different kinds of words.
For example, say a string literal is being passed in a function call. In essence, there are two bits of information for a programmer to be aware of:
1. A string literal is being passed
2. The contents of the string
Now, it is *right* that those things can be considered separately. It's right that I can saccade past the contents of the string if right now I'm not interested in that argument, and need to examine another argument to the function more closely.
It is wrong to be forced every time to track my eyes across carefully, and find the closing quote, before I can look at the next argument to the function. These little inefficiencies add up.
The analogy with a novel is false. A novel must be read in a linear fashion. For most modern code paradigms it's not even clear what linear would mean (a source file, a stack trace, an inheritance hierarchy?). Furthermore the English language does not have the same kind of formal syntactic structures as code: function calls, literals, operators, macros etc are not merely different kinds of words.
Anonymous
Sat 18-May-2013 11:57
Sat 18-May-2013 11:57
So much for the 'age of information'.
Well, it is the age of information. Noone said it was the age of wisdom.
Anonymous
Sat 18-May-2013 12:08
Sat 18-May-2013 12:08
"yes" program , produced in 2009 !
Thank you David McKenzie for your contribution to open source community !
I am just wondering what in your background that enabled the FSF to accept such worthless contribution ?
Member of what masonic lodge or what church or son of a war hero or billonarties you have to be so they accept that piece of crap ?
For reference:
yes command - otputs a line on tty until killed !
coded and added to Linux in 2009.
Thank you David McKenzie for your contribution to open source community !
I am just wondering what in your background that enabled the FSF to accept such worthless contribution ?
Member of what masonic lodge or what church or son of a war hero or billonarties you have to be so they accept that piece of crap ?
For reference:
yes command - otputs a line on tty until killed !
coded and added to Linux in 2009.
Actually, "yes", which is part of GNU coreutils, has been around since, like forever, being an implementation of the same-named Unix command.
David MacKenzie is the author of many of coreutils' commands, including chgrp, chmod, chown, date, dirname, expand, fold, ginstall, groups, head, mkdir, mkfifo, mknod, nice, printenv, printf, rmdir, stty, su, tty, uname, unexpand, and obviously yes; and is co-author of many others. But he is probably best known for autotools, which is one of the most central pieces of free software, as any distribution maintainer could tell you.
Now, what have YOU done for GNU or Linux or free software?
Anonymous
Sat 18-May-2013 23:01
Sat 18-May-2013 23:01
Very well done!
chipxsd
Klemen Verdnik
Wed 22-May-2013 10:52
Klemen Verdnik
Wed 22-May-2013 10:52
you're one crazy sonofabitch! :) that's one hell of a job you did there. I can't wait to see the fluidity of other demos using this tool.
And the example demo you provided is also cute (music, plasma and the morphing logo).
I really like coming to your site, you really amaze me :) Any chance you'll be playing around with Propeller II, when it comes out (or with the FPGA version)?
And the example demo you provided is also cute (music, plasma and the morphing logo).
I really like coming to your site, you really amaze me :) Any chance you'll be playing around with Propeller II, when it comes out (or with the FPGA version)?
Getting string input (TI-83 assembly programming)
Anonymous
Sun 26-May-2013 17:21
Sun 26-May-2013 17:21
How to do in x86 assembly ?
A case against syntax highlighting
HoltomS
Stephen Holtom
Mon 27-May-2013 05:11
Stephen Holtom
Mon 27-May-2013 05:11
It also occurs to me that you've had a bit of a free pass with the "seeing the woods for the trees" comment. It's the kind of statement that seems intuitively right, and most programmers at first glance would consider it to be important.
But on reflection, I don't believe it is important, or even correct.
For any sufficiently complex program, abstraction is incredibly important.
When I'm writing a class I should be concerned with just what that particular class does. And in terms of calling other classes, it should be safe to forget how they internally work. If I can't do this then this implies poor design and a creaky system. And needless to say, there should not be global variables, or shared states. I should be able to focus on a single method at a time because everything is so neatly encapsulated.
So being able to work at the "trees" level is actually an ideal.
Now I'm sure you'll say that what you mean is the big picture: an awareness of what the whole shebang is doing, and is for.
But again, for sufficiently complex programs that level is far above the level of actually looking at source code. Understanding the big picture, and your preferences for displaying code, are very far removed.
But on reflection, I don't believe it is important, or even correct.
For any sufficiently complex program, abstraction is incredibly important.
When I'm writing a class I should be concerned with just what that particular class does. And in terms of calling other classes, it should be safe to forget how they internally work. If I can't do this then this implies poor design and a creaky system. And needless to say, there should not be global variables, or shared states. I should be able to focus on a single method at a time because everything is so neatly encapsulated.
So being able to work at the "trees" level is actually an ideal.
Now I'm sure you'll say that what you mean is the big picture: an awareness of what the whole shebang is doing, and is for.
But again, for sufficiently complex programs that level is far above the level of actually looking at source code. Understanding the big picture, and your preferences for displaying code, are very far removed.
Anonymous
Wed 29-May-2013 23:57
Wed 29-May-2013 23:57
i just stumbled upon this through youtube. i am amazed you did this all on your own!! you guys in sweden are bad ass :D have the best day!!