 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Available at:
https://sourceforge.net/projects/logicsim/files/
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mmm, somebody heard my typing. ;-)
Pretty icon, BTW.
I did think about mentioning some of the more amusing features of this
build... but I figured you already know about them anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/14/2010 7:21 AM, Invisible wrote:
> Mmm, somebody heard my typing. ;-)
>
> Pretty icon, BTW.
>
> I did think about mentioning some of the more amusing features of this
> build... but I figured you already know about them anyway.
Do mention... I want to know.
What? the fact that if you wire a feeback loop the program just dies a
horrible death?
The fact that no menus work yet?
The irritation that when you go and change something on the property
grid the main window loses keyboard focus and it seems impossible to
regain it?
Really.. I want to know the bugs, though, if it isn't those issues. If
it is those issues, I'm aware of them. Right now I'm just trying to get
the basic pieces in.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> On 6/14/2010 7:21 AM, Invisible wrote:
>> Mmm, somebody heard my typing. ;-)
>>
>> Pretty icon, BTW.
>>
>> I did think about mentioning some of the more amusing features of this
>> build... but I figured you already know about them anyway.
>
> Do mention... I want to know.
>
> What? the fact that if you wire a feeback loop the program just dies a
> horrible death?
>
> The fact that no menus work yet?
>
> The irritation that when you go and change something on the property
> grid the main window loses keyboard focus and it seems impossible to
> regain it?
No, more things like...
- If you select "OR gate", it inserts a NOR gate.
- NAND has the same truth table as NOR.
- If you change an input's value from the property pane, the simulation
doesn't update. (I didn't immediately notice the ability to "poke" the
inputs to change them. It's also mildly irritating that you have to
cycle through 0, 1 and Z.)
- You can't delete stuff, only add it. ;-)
- The selection marks look fine for 1-input gates, but for 2-input gates
it looks kinda weird having a box between the two inputs.
I was espectially ticked by the first two - but I didn't wanna sound
mean. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/14/2010 8:43 AM, Invisible wrote:
>
> No, more things like...
>
> - If you select "OR gate", it inserts a NOR gate.
>
> - NAND has the same truth table as NOR.
Crap! I must have screwed something up when building some of the other
items... That's a regression error. I'll have to take care of that.
> - If you change an input's value from the property pane, the simulation
> doesn't update. (I didn't immediately notice the ability to "poke" the
> inputs to change them. It's also mildly irritating that you have to
> cycle through 0, 1 and Z.)
Yeah, the sim isn't updating right now when the properties are altered.
There's reasons I'm not addressing this as of yet, mainly to do with the
fact that I'm going to rewrite the simulation core, and at that point it
won't matter how the property is altered.
Only if the input is 3-state do you have to cycle through the states.
> - You can't delete stuff, only add it. ;-)
Yeah, an annoyance for sure ... But, hey, pre-alpha. ;)
In truth I just haven't gotten around to coding some of the more trivial
things, yet.
> - The selection marks look fine for 1-input gates, but for 2-input gates
> it looks kinda weird having a box between the two inputs.
The handles will eventually allow you to elongate the connecting pins,
and change orientation by drag on gates. Its not there yet. It might
make sense later, when it actually functions...
> I was espectially ticked by the first two - but I didn't wanna sound
> mean. ;-)
No! This is good stuff! I need feedback like this Obviously I miss
things like this when coding the application.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> - If you select "OR gate", it inserts a NOR gate.
>>
>> - NAND has the same truth table as NOR.
>
> Crap!
Uh, yes. ;-) That's a kind of elementary mistake, right there. (Which is
why I assumed you had already noticed it, but I guess not...)
> That's a regression error. I'll have to take care of that.
Yah. ;-)
>> - You can't delete stuff, only add it. ;-)
>
> Yeah, an annoyance for sure ... But, hey, pre-alpha. ;)
Well, yeah. The thing I'm writing is currently just a few miles of
function calls. It doesn't even *do* anything visible yet!
> In truth I just haven't gotten around to coding some of the more trivial
> things, yet.
Ain't that always the way? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've just been prodding the 15-Jun build. I presume you know these
already, but...
Adding a tristate buffer works, but not a tristate inverter. Also,
neither the clock source nor the splitter work, but I guess that's
intensional.
For the first time, I tried actually wiring together a simple circuit.
Wiring seems to be quite buggy. Sometimes you join wires together and
they don't actually join. Sometimes they look like they aren't joined,
but when you connect the other end of the wire to something, suddenly it
works. And sometimes it's difficult to figure out just what on Earth is
going on. (Especially since you can't, say, delete the wires you've
already made. *g*)
Still, I've spent several days now just trying to build the internal API
to manage something like this, and I'm getting nowhere, rapidly...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/14/2010 9:45 AM, Invisible wrote:
>>> - If you select "OR gate", it inserts a NOR gate.
>>>
>>> - NAND has the same truth table as NOR.
>>
>> Crap!
>
> Uh, yes. ;-) That's a kind of elementary mistake, right there. (Which is
> why I assumed you had already noticed it, but I guess not...)
>
>> That's a regression error. I'll have to take care of that.
>
> Yah. ;-)
>
Well, the NAND = NOR thing was a total cluster****, I don't know what I
was thinking when I coded NAND. I have a feeling that code was probably
written at 1:00am on a Saturday morning. How it got by me testing it is
a total mystery. It was so obviously wrong for NAND.
The OR gate placing a NOR gate was interesting. I have a function that
checks the types and caches the last used values for later use. Since
OR, XOR and NOR all have the same basic drawing OR is the base class for
those, only changing a few minor details (such as the extra curve on the
input side of the XOR, and the output bubble on NOR), so, it would see
that it could be cast to an OR and consequently dump it into the
PreviousOrGate variable. Oops. I corrected the case with NOR, but
discovered XOR only after I uploaded the code.
>
> Well, yeah. The thing I'm writing is currently just a few miles of
> function calls. It doesn't even *do* anything visible yet!
>
Your own sim? How is it going? ( as far as the function calls go, I guess? )
>> In truth I just haven't gotten around to coding some of the more
>> trivial things, yet.
>
> Ain't that always the way? ;-)
Yep.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> - If you select "OR gate", it inserts a NOR gate.
>>>>
>>>> - NAND has the same truth table as NOR.
>>>
>>> Crap!
>>
>> Yah. ;-)
>>
>
> Well, the NAND = NOR thing was a total cluster****, I don't know what I
> was thinking when I coded NAND. I have a feeling that code was probably
> written at 1:00am on a Saturday morning.
Oh, one of *those*... ;-)
I generally just don't code anything at that hour. It never ****ing
works right anyway.
> How it got by me testing it is
> a total mystery. It was so obviously wrong for NAND.
Heh, well, I did wonder. Actually, as I say, I just assumed that since
it was *so* wrong, you must already know about it but just haven't got
round to fixing it yet.
> The OR gate placing a NOR gate was interesting. I have a function that
> checks the types and caches the last used values for later use. Since
> OR, XOR and NOR all have the same basic drawing OR is the base class for
> those, only changing a few minor details (such as the extra curve on the
> input side of the XOR, and the output bubble on NOR), so, it would see
> that it could be cast to an OR and consequently dump it into the
> PreviousOrGate variable. Oops. I corrected the case with NOR, but
> discovered XOR only after I uploaded the code.
Pah. Mutable state is evil! ;-)
>> Well, yeah. The thing I'm writing is currently just a few miles of
>> function calls. It doesn't even *do* anything visible yet!
>
> Your own sim? How is it going? ( as far as the function calls go, I
> guess? )
Very, very slowly. Like, I'm having trouble making it so that I can add
and remove wires and stuff efficiently and still be able to look up what
connects to what efficiently and...
(See my post about "highly redundant data structures.)
You, by comparison, have got something that *runs*. I'm still faffing
around with design choices.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/15/2010 1:53 PM, Orchid XP v8 wrote:
> Adding a tristate buffer works, but not a tristate inverter. Also,
> neither the clock source nor the splitter work, but I guess that's
> intensional.
Yep. Those aren't there yet.
> For the first time, I tried actually wiring together a simple circuit.
> Wiring seems to be quite buggy. Sometimes you join wires together and
> they don't actually join. Sometimes they look like they aren't joined,
> but when you connect the other end of the wire to something, suddenly it
> works. And sometimes it's difficult to figure out just what on Earth is
> going on. (Especially since you can't, say, delete the wires you've
> already made. *g*)
The problem, I think (aside from not being able to delete things...) is
kind of two-fold... Connecting the pins while on the surface seemed very
simple, some cases quickly become a royal PITA.... There are some
modifier keys in wiring that will cause some of the connection stuff to
behave differently, generally if it has an orange indicator, it should
be connected when you release the mouse button. The other half of it is
that it appears to have not connected because it doesn't always take the
characteristics of what you just connected it to until the other end is
connected to something else. This has more to do with the sim core, though.
There's also a major annoyance with-- for example-- altering the layout
of a circuit. You pull a wire from one location, leaving 2 wires
connected straight together, you then draw a new wire across that
junction (which happens to be invisible...) and it joins everything at
that intersection. One of the things I need to do is when reconciling
the wires, ensure any wires that are joined at the same angle get
consolidated into a single wire. After drawing wires for a few minutes I
was able to slice and dice a single wire into a dozen pieces. Nasty.
> Still, I've spent several days now just trying to build the internal API
> to manage something like this, and I'm getting nowhere, rapidly...
That happens with lots of things ;)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/15/2010 2:59 PM, Orchid XP v8 wrote:
>
> I generally just don't code anything at that hour. It never ****ing
> works right anyway.
>
Yeah, probably good advice. ;)
> Heh, well, I did wonder. Actually, as I say, I just assumed that since
> it was *so* wrong, you must already know about it but just haven't got
> round to fixing it yet.
There are some things like that in there at the moment, but that was not
one of them.
>
> Pah. Mutable state is evil! ;-)
>
Eh, I'm thinking of a way of managing that part of the app in a much
cleaner manner, anyway.
You have to change the state of the objects somehow....
> Very, very slowly. Like, I'm having trouble making it so that I can add
> and remove wires and stuff efficiently and still be able to look up what
> connects to what efficiently and...
My progress isn't as quick (or as clean) as I would like, but yeah... I
had similar challenges. Quadtrees help if you're looking for something
at a particular location, btw ;)
> (See my post about "highly redundant data structures.)
I'll have a look at this...
> You, by comparison, have got something that *runs*. I'm still faffing
> around with design choices.
Yeah, it limps along, I suppose ;)
You're coding it in Haskell, aren't you?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Pah. Mutable state is evil! ;-)
>
> You have to change the state of the objects somehow....
Do not try to change the state of the objects. Instead only try to
realise the truth: there is no state. Then you will see that it is not
the *state* that changes, it is only *yourself*. ;-)
>> Very, very slowly. Like, I'm having trouble making it so that I can add
>> and remove wires and stuff efficiently and still be able to look up what
>> connects to what efficiently and...
>
> My progress isn't as quick (or as clean) as I would like, but yeah... I
> had similar challenges. Quadtrees help if you're looking for something
> at a particular location, btw ;)
Oh hell, I haven't even got that far. When the inputs to a gate change,
and its output changes, it has to notify everything connected to its
output. But to do that, you have to be able to somehow look up what it's
connected to... and be able to change it later... and check that you
don't have outputs connected to other outputs... and...
>> (See my post about "highly redundant data structures.)
>
> I'll have a look at this...
There's really nothing to see. I just meant that that's what my comment
is about. ;-) Because I want to look up information five different ways,
it's in five different indexes, all of which need to agree with each
other...
>> You, by comparison, have got something that *runs*. I'm still faffing
>> around with design choices.
>
> You're coding it in Haskell, aren't you?
You trying to imply there's a causality relationship there? :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/15/2010 3:41 PM, Orchid XP v8 wrote:
>>> Pah. Mutable state is evil! ;-)
>>
>> You have to change the state of the objects somehow....
>
> Do not try to change the state of the objects. Instead only try to
> realise the truth: there is no state. Then you will see that it is not
> the *state* that changes, it is only *yourself*. ;-)
>
Welcome to the Matrix, Neo.
>
> Oh hell, I haven't even got that far. When the inputs to a gate change,
> and its output changes, it has to notify everything connected to its
> output. But to do that, you have to be able to somehow look up what it's
> connected to... and be able to change it later... and check that you
> don't have outputs connected to other outputs... and...
>
Yup, been there .. still there .. still not exactly what I want. Mine is
a bit more weird than that. I start somewhere, and begin fanning out
looking at various pin states, If I see more than one output, I flag
it... and so on. It's a sucktacular process and has many, many failings.
Plus, it doesn't lend itself very well to being able to follow signals,
being able to step from gate to gate, being able to follow a particular
signal path into a subcircuit...
>>> (See my post about "highly redundant data structures.)
>>
>> I'll have a look at this...
>
> There's really nothing to see. I just meant that that's what my comment
> is about. ;-) Because I want to look up information five different ways,
> it's in five different indexes, all of which need to agree with each
> other...
>
That's ok.. I couldn't find the post anyway.
>>> You, by comparison, have got something that *runs*. I'm still faffing
>>> around with design choices.
>>
>> You're coding it in Haskell, aren't you?
>
> You trying to imply there's a causality relationship there? :-P
>
Oh, no ... But I did have to get a Haskell dig in somewhere ;)
I am interested in seeing what your Haskell implementation will be like.
(In a way, this reminds me a bit of a small friendly "competition"
between a friend of mine and I back when I was a kid. We both wrote
different implementations of the same game....)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Oh hell, I haven't even got that far. When the inputs to a gate change,
>> and its output changes, it has to notify everything connected to its
>> output. But to do that, you have to be able to somehow look up what it's
>> connected to... and be able to change it later... and check that you
>> don't have outputs connected to other outputs... and...
>>
>
> Yup, been there .. still there .. still not exactly what I want. Mine is
> a bit more weird than that. I start somewhere, and begin fanning out
> looking at various pin states, If I see more than one output, I flag
> it... and so on. It's a sucktacular process and has many, many failings.
> Plus, it doesn't lend itself very well to being able to follow signals,
> being able to step from gate to gate, being able to follow a particular
> signal path into a subcircuit...
>>> You're coding it in Haskell, aren't you?
>>
>> You trying to imply there's a causality relationship there? :-P
>>
>
> Oh, no ... But I did have to get a Haskell dig in somewhere ;)
>
> I am interested in seeing what your Haskell implementation will be like.
Coding stuff in Haskell encourages you to try to make everything
"perfect", which is possibly why I'm still designing and redesigning the
thing rather than making it actually do stuff...
Small example: Different gates have different numbers of pins. Now in an
OO language, you'd probably just have an array (or some other container)
of pins and be done with it. You *could* do that in Haskell too,
except... well... there's always the possibility of a gate ending up
with the wrong number of pins. In an OO language, you'd probably just
ignore that possibility, in which case the code will throw some kind of
exception if the number of pins is wrong. But in Haskell, you're more or
less forced to explicitly handle this possibility. And that tends to
discourage you from ignoring it, since if this happens, there's
basically no good way to recover. (You just throw an exception I guess -
which is quite frowned - or you make your functions explicitly partial,
which is quite a bit more work.)
The net result is that in Haskell, you take more notice of this problem.
And it turns out that by using ADTs, it's quite simple to statically
prevent the problem from ever occuring in the first place. So you can
design your code so that there's this problem that might happen that you
have to explicitly test for and explicitly deal with, or you can design
your program so that the problem is guaranteed to never happen in the
first place. Guess which option the typical Haskell programmer is going
to go for. ;-)
Of course, making everything "perfect" like this requires quite a lot of
think-time. Haskell strongly encourages this style of "think twice, code
once". Anyway, I believe I'm closing in on a solution, but I'll believe
it when the code actually runs properly!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I am interested in seeing what your Haskell implementation will be like.
>
> Coding stuff in Haskell encourages you to try to make everything
> "perfect", which is possibly why I'm still designing and redesigning the
> thing rather than making it actually do stuff...
>
> Of course, making everything "perfect" like this requires quite a lot of
> think-time. Haskell strongly encourages this style of "think twice, code
> once". Anyway, I believe I'm closing in on a solution, but I'll believe
> it when the code actually runs properly!
Yeah, the internal layout management code appears to be operating
correctly now. In the end, I applied a tried and tested analysis
technique: a relational-style ERD.
The problem was that I'd design a data structure, start coding away, and
then discover some query direction that wasn't easy to support. So then
I'd change the data structure, which makes half the code break, so I
have to go rewrite that... In the end, the solution was to sit down and
draw out a propper plan. Once you comprehend the exact structure of the
information you want to store and the directions in which you want to
access it, you can come up with a nice *simple* data structure which
does what you actually need.
It works a lot better now - although I'm still finding minor bugs here
and there...
Who knows? I might even get the simulation algorithm running today.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Who knows? I might even get the simulation algorithm running today.
Affirm that. After many hours' work, I have now reached the point where
I've simulated a binary half adder which correctly computed that 0 + 0 =
0 carry 0. Woo.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> The net result is that in Haskell, you take more notice of this problem.
Hate to tell you, you take notice of it in an OO language also. :-) It's not
any easier to deal with things like that.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The net result is that in Haskell, you take more notice of this problem.
>
> Hate to tell you, you take notice of it in an OO language also. :-)
I didn't intend to make any absolute statements. I just meant that in
general, Haskell tends to make you notice certain things more.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> I am interested in seeing what your Haskell implementation will be like.
OK, so I just finished the 6th complete rewrite of the LogicWorks
simulation core. And it seems to be working, as best as I can tell.
I spent a long time trying to hyper-compartmentalise the thing so that
every tiny aspect of its operation was a seperate source file, with a
tightly-controlled interface to it. The trouble is, everything depends
on everything else, so you end up going mad trying to avoid circular
module dependencies. Eventually I just put everything related to
simulation into one utterly giant module. Circular dependencies within
the same module don't matter. ;-)
Secondly, I spent ages trying to design the circuit as a dozen seperate
data structures, each representing different facets of its operation,
and several different modes of operation depending on what you want to
alter. And then I realised that in the real application, you only want
one mode: the mode where you can modify the live circuit as you simulate
it, and everything needed to do the simulation is one data object. So
instead of having dozens of datatypes, I put everything into one big
record and wrote all my functions to work on that.
The net result is what I'd consider to be utterly huge, although other
people's opinions may differ. It's a single source file, 660 lines long
(including comments) and 20 KB in size. When you compile it, it
generates a 38 KB interface file plus a 182 KB object file.
(For reference, I usually structure my programs so that each module is
about 150 lines or so.)
It's about now that an IDE starts to sound attractive. It would be nice
to be able to glance at a panel and see the sames and types of all the
functions I've written, and be able to quickly navigate to them.
Actually, hell, just some syntax hilighting would be nice! Oh well...
Anyway, I could show you the code if you _want_, but... it's kinda
large. (And most of it is just searching for or storing data, which
isn't tremendously interesting.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Eventually I just put everything related to
> simulation into one utterly giant module. Circular dependencies within
> the same module don't matter. ;-)
I assume you're doing this in Haskell? I haven't really been paying too much
attention.
> It's about now that an IDE starts to sound attractive. It would be nice
> to be able to glance at a panel and see the sames and types of all the
> functions I've written, and be able to quickly navigate to them.
Now you're getting it. :-)
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>> Eventually I just put everything related to simulation into one
>> utterly giant module. Circular dependencies within the same module
>> don't matter. ;-)
>
> I assume you're doing this in Haskell? I haven't really been paying too
> much attention.
Yeah, it's Haskell. Surprised? ;-)
>> It's about now that an IDE starts to sound attractive. It would be
>> nice to be able to glance at a panel and see the sames and types of
>> all the functions I've written, and be able to quickly navigate to them.
>
> Now you're getting it. :-)
I did think about trying Leksah the other day - but I couldn't be
bothered with solving the dependency hell in order to make it compile...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/24/2010 10:36 AM, Invisible wrote:
> Anyway, I could show you the code if you _want_, but... it's kinda
> large. (And most of it is just searching for or storing data, which
> isn't tremendously interesting.)
Yeah, show me ... :)
660 doesn't seem like much in terms of code size. I'm pretty sure my
program is a few more lines. ;)
Right now I'm attempting to move a lot of the interaction stuff into
separate modules outside of the main control. Problem is there's a ton
of interdependency between the user interaction code an the actual
control (big surprise there) I'm thinking about nesting the interaction
modules into the main control so I can keep the protected and private
stuff protected and private (One thing C# lacks that can be a bit
irksome sometimes is the lack of a friend declaration for classes that
are tightly coupled to a particular class. (Yeah... I know-- coupling
between classes should be loose, but in some situations it makes sense.)
Posting the source for all to see has made me a bit ... nervous, though.
This is the first time I've actually gone open-source on something and I
feel a bit vulnerable and open to ridicule... no one has yet... but it
could happen. I get nice comments from people I work with regarding my
code, but those are co-workers... they have to be nice. ;)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Anyway, I could show you the code if you _want_, but... it's kinda
>> large. (And most of it is just searching for or storing data, which
>> isn't tremendously interesting.)
>
> Yeah, show me ... :)
You'll be sorry. ;-)
I think I'll post it on our Haskell newsgroup, if that's OK?
> 660 doesn't seem like much in terms of code size. I'm pretty sure my
> program is a few more lines. ;)
We're talking about a programming language where quicksort is 2 lines of
code. 660 is pretty huge. ;-)
The main reason I keep individual files small is to make it faster to
navigate. I don't like having to scroll through pages and pages to get
to where I want. But hey...
I wouldn't even mind so much, but a lot of the code is fairly mundane.
Insert this value, delete that one, search for this key, etc.
> Right now I'm attempting to move a lot of the interaction stuff into
> separate modules outside of the main control.
Heh, yeah, good luck with that. ;-)
> Posting the source for all to see has made me a bit ... nervous, though.
> This is the first time I've actually gone open-source on something and I
> feel a bit vulnerable and open to ridicule... no one has yet... but it
> could happen.
Yeah, I put a couple of trivial libraries onto Hackage [the central
Haskell package DB]. One person complained that the RGB colourspace
isn't linear [which obviously it damned-well should be]. Somebody else
said that my vector package did the same thing as an already-existing
package. That kind of thing. But for the most part, nobody even noticed.
Trust me, people notice you way, way less than you think...
> I get nice comments from people I work with regarding my
> code, but those are co-workers... they have to be nice. ;)
Do they?? o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/25/2010 8:17 AM, Invisible wrote:
> I think I'll post it on our Haskell newsgroup, if that's OK?
>
Yeah, that'll work/
>> 660 doesn't seem like much in terms of code size. I'm pretty sure my
>> program is a few more lines. ;)
>
> We're talking about a programming language where quicksort is 2 lines of
> code. 660 is pretty huge. ;-)
>
I see (I think ...)
>> Right now I'm attempting to move a lot of the interaction stuff into
>> separate modules outside of the main control.
>
> Heh, yeah, good luck with that. ;-)
>
Yeahhhh... It's a bit of challenge from the design standpoint.
> Yeah, I put a couple of trivial libraries onto Hackage [the central
> Haskell package DB]. One person complained that the RGB colourspace
> isn't linear [which obviously it damned-well should be]. Somebody else
> said that my vector package did the same thing as an already-existing
> package. That kind of thing. But for the most part, nobody even noticed.
> Trust me, people notice you way, way less than you think...
Ach... true, tho as someone once said (on people talking amongst
themselves in their own national language, in particular in the US that
would be Spanish) You're just not that interesting to other people.
They're speaking in their own language because they're more comfortable
doing that. My wife knows Spanish very well. She can back that up.
Usually it's just mundane family stuff or gossip about work.
>> I get nice comments from people I work with regarding my code, but
>> those are co-workers... they have to be nice. ;)
>
> Do they?? o_O
Eh, it makes it easier to work with others if you're nice to them. :)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I think I'll post it on our Haskell newsgroup, if that's OK?
>
> Yeah, that'll work/
See you on povray.off-topic.fan.haskell.bork.bork.bork in a little
while. ;-)
(Of course, dumping the code will take about 3 mouse clicks explaining
what it *does* is another matter...)
>>> Right now I'm attempting to move a lot of the interaction stuff into
>>> separate modules outside of the main control.
>>
>> Heh, yeah, good luck with that. ;-)
>
> Yeahhhh... It's a bit of challenge from the design standpoint.
Trust me, it's easier if you start with everything seperated from the
very beginning. ;-)
>> Trust me, people notice you way, way less than you think...
>
> Ach... true, tho as someone once said
> You're just not that interesting to other people.
It's true.
>>> I get nice comments from people I work with regarding my code, but
>>> those are co-workers... they have to be nice. ;)
>>
>> Do they?? o_O
>
> Eh, it makes it easier to work with others if you're nice to them. :)
Ooo. I must try this...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> irksome sometimes is the lack of a friend declaration for classes that
> are tightly coupled to a particular class.
That's what "internal" is for. :-) Not quite as precise, true.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/25/2010 11:25 AM, Darren New wrote:
> Mike Raiford wrote:
>> irksome sometimes is the lack of a friend declaration for classes that
>> are tightly coupled to a particular class.
>
> That's what "internal" is for. :-) Not quite as precise, true.
>
Right... but that makes it available assembly-wide, when I don't want it
available assembly-wide. Oh well...
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Right... but that makes it available assembly-wide, when I don't want it
> available assembly-wide. Oh well...
Then your assembly might be too large. :-) But since everything in the
assembly is by definition tightly coupled, I'm not sure why comments as to
who is supposed to be using it aren't sufficient. Beyond just theoretical
OCDness.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/25/2010 12:01 PM, Darren New wrote:
> Then your assembly might be too large. :-) But since everything in the
> assembly is by definition tightly coupled, I'm not sure why comments as
> to who is supposed to be using it aren't sufficient. Beyond just
> theoretical OCDness.
Yeah, you just nailed it there .... Theoretical OCDness..:D
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
