KTechlab

On Wed, 11 Feb 2009 21:03:29 +0100, Lawrence Shafer <detroit371@...>  
wrote:

> I was just playing with a couple of sub-circuits, and noticed that when
> a sub-circuit  is added to the sheet, a whole bunch (a real mess) of
> wires get added too. I also cant get my subcircuit to behave properly
> after deleting the wires. This is with the SVN version from yesterday.
> 2009-02-10
>
> I'm not sure if you want to deal with these little things from svn on
> the bugtracker, or not, so I'm just posting them here.
>

  Confirmed in the 0.3.7 branch :(

  Here's a log from ktechlab, showing the output of adding a simple  
subcircuit to an empty circuit:

ktechlab: [Connector::Connector(Node*, Node*, ICNDocument*, QString*)]  
Connector attempted to register given ID, but ID already in use: connector
ktechlab: Creating a new one: connector__6
ktechlab: [Connector::Connector(Node*, Node*, ICNDocument*, QString*)]  
Connector attempted to register given ID, but ID already in use:  
connector__2
ktechlab: Creating a new one: connector__7
ktechlab: [Connector::Connector(Node*, Node*, ICNDocument*, QString*)]  
Connector attempted to register given ID, but ID already in use:  
connector__10
ktechlab: Creating a new one: connector__15
ktechlab: [Connector::Connector(Node*, Node*, ICNDocument*, QString*)]  
Connector attempted to register given ID, but ID already in use:  
connector__11
ktechlab: Creating a new one: connector__16
-------
State is:
<!DOCTYPE KTechlab>
<document type="circuit" >
  <item x="276" y="164" z="0" type="ec/subcircuit" id="subcircuit" flip="0"  
angle="0" >
   <data value="2" type="number" id="id" />
  </item>
  <connector start-node-is-child="1" manual-route="0"  
end-node-parent="resistor" route="" end-node-cid="n1"  
start-node-parent="subcircuit" start-node-cid="0"id="connector__15"  
end-node-is-child="1" />
  <connector start-node-is-child="1" manual-route="0"  
end-node-parent="resistor" route="" end-node-cid="p1"  
start-node-parent="subcircuit" start-node-cid="1"id="connector__16"  
end-node-is-child="1" />
</document>

  It seems to me that the bug is caused by not hiding the connectors from  
the internal structure of the subcircuit (I guess ktechlab is just dumping  
the contents of the subcircuit on the actual circuit, but makes is hidden).

> Lawrence
>

On Friday 13 February 2009 16:38:26 P Zoltan wrote:
>   It seems to me that the bug is caused by not hiding the connectors from
> the internal structure of the subcircuit (I guess ktechlab is just dumping
> the contents of the subcircuit on the actual circuit, but makes is hidden).
Thanks for your research! Can we work-around this by adding some logic 
somewhere? It would be nice if we only need to change the sub-circuit 
component class. It just needs to be aware that it was dropped into a circuit 
and create unique connectors (or even items, don't know if it could happen to 
items, too) before actually performing the operation.

I might have a look at that later.. Need to get some food now ;)

bye then
julian

On Fri, 13 Feb 2009 15:53:37 +0100, Julian Bäume <julian@...> wrote:

> On Friday 13 February 2009 16:38:26 P Zoltan wrote:
>>   It seems to me that the bug is caused by not hiding the connectors  
>> from
>> the internal structure of the subcircuit (I guess ktechlab is just  
>> dumping
>> the contents of the subcircuit on the actual circuit, but makes is  
>> hidden).
> Thanks for your research! Can we work-around this by adding some logic
> somewhere? It would be nice if we only need to change the sub-circuit
> component class. It just needs to be aware that it was dropped into a  
> circuit
> and create unique connectors (or even items, don't know if it could  
> happen to
> items, too) before actually performing the operation.
>

  Some more results: it doesn't work as I thought. The simulator "needs"  
those connectors for the simulation, but they somehow get "out" of the  
subcircuit. Another note: if in the Connector constructor no new ids are  
generated, just let the new component override the old, these lost  
connectors don't appear.

On Friday 13 February 2009 19:43:40 P Zoltan wrote:
>   Some more results: it doesn't work as I thought. The simulator "needs"  
> those connectors for the simulation, but they somehow get "out" of the  
> subcircuit. Another note: if in the Connector constructor no new ids are  
> generated, just let the new component override the old, these lost  
> connectors don't appear.

I can confirm that ;) the problem is that mixing up GUI and logical data is 
bad. Another thing I mentioned while playing around with sub-circuits is, that 
they aren't consistent. The sub-circuits aren't stored within circuit files. 
(Or did I got something wrong?) This should mess everything up, when loading 
an "old" circuit file containing a sub-circuit, that is not in the users 
KTechLab directory. This will probably not happen this often on a single-user 
system, but as more people share their circuit files, this will become a real 
problem. Much rework is needed here, if I got everything right.

bye then
julian

PS: I'm looking for a solution to work-around this issue, because this is 
quite annoying, even if you don't mess up everything by changing your local 
sub-circuits.

> PS: I'm looking for a solution to work-around this issue, because this is
> quite annoying, even if you don't mess up everything by changing your  
> local
> sub-circuits.

  Here are some findings after 2 hours of debugging:

  In
  void SubcircuitData::initECSubcircuit( ECSubcircuit * ecSubcircuit )
the member m_connectorDataMap contains connectors with the ids that  
collide with the newly created ids. In a strange manner, those connectors  
go from node with id "" to another node with id "" (that is empty string).

  If the circuit is printed with the toXML() method, those connectors don't  
show up in the output. :|

  Some general info: in the above mentioned method "this" is the subcircuit  
to be merged and the parameter of the method represents the cicuit seen by  
the user.

  Debugging this still sucks for me, because of the program is interrupted  
when a dragging operation is in process, the mouse becomes unusable for me  
(it has a "can't drop here" cursor, and can't make clicks).

  A quick-and-dirty solution^H^Hhack would be to control the behaviour of  
the Connector constructor by setting a static parameter in the class: if  
it's not set, it doesn't allow to override existing connector ids, and if  
it's set, it allows such operation. If we don't want to clean up the 0.3  
branch, and just go for the rewrite, we could accept this hacks.  
Otherwise, prepare the debuggers.. :)

>   Some general info: in the above mentioned method "this" is the subcircuit  
> to be merged and the parameter of the method represents the cicuit seen by  
> the user.

I seem to have a problem with my build or something, I haven't had
pop-up menus in a dog's age and don't see any subcircuit feature anywhere.

This is an important functionality, especially in light of the bench
testing framework I want
to add. =(

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.

Add an "External Connection" to the circuit, Select all, then right 
click for "create sub-circuit."

Bryan


Alan Grimes wrote:
>>   Some general info: in the above mentioned method "this" is the subcircuit  
>> to be merged and the parameter of the method represents the cicuit seen by  
>> the user.
>>     
>
> I seem to have a problem with my build or something, I haven't had
> pop-up menus in a dog's age and don't see any subcircuit feature anywhere.
>
> This is an important functionality, especially in light of the bench
> testing framework I want
> to add. =(
>
>

On Mon, 16 Feb 2009 00:48:55 +0100, Alan Grimes <agrimes@...>  
wrote:

>
> I seem to have a problem with my build or something, I haven't had
> pop-up menus in a dog's age and don't see any subcircuit feature  
> anywhere.
>

  When you right-click on a circuit, you should see a menu. The last entry  
should be "create subcircuit". If the menu doesn't appear, your ktechlab  
installation is probably broken.


  More news: the root of this issue is ItemDocument, which seems to  
register UIDs, and fails to unregister them -- even if there is no item  
associated to that UID. I've comitted in the 0.3.7 branch a fix which  
unregisters the UID of the connector right before creating the connector.  
Now the bug had disappeared, and I hope it didn't create other bugs.  
Please test it. :)

  Zoltan

P Zoltan wrote:
> On Mon, 16 Feb 2009 00:48:55 +0100, Alan Grimes <agrimes@...>  

>> I seem to have a problem with my build or something, I haven't had
>> pop-up menus in a dog's age and don't see any subcircuit feature  
>> anywhere.

>   When you right-click on a circuit, you should see a menu. The last entry  
> should be "create subcircuit". If the menu doesn't appear, your ktechlab  
> installation is probably broken.

Yeah, I gathered that, any hints for tracking this down and fixing it? =(


I did some profiling on the code and found that my own matrix and vector
classes were taking a hefty chunk of the time in the [] operators. I am
now running some tests on whether making them explicitly inline will
help GCC be a bit less mentally retarded in compiling them. =P

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
P Zoltan wrote:
<blockquote cite="mid:op.upieiuxj4dckcr@..."
 type="cite">
  <pre wrap="">On Mon, 16 Feb 2009 00:48:55 +0100, Alan Grimes <a class="moz-txt-link-rfc2396E" href="mailto:agrimes@...>  
wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">I seem to have a problem with my build or something, I haven't had
pop-up menus in a dog's age and don't see any subcircuit feature  
anywhere.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  When you right-click on a circuit, you should see a menu. The last entry  
should be "create subcircuit". If the menu doesn't appear, your ktechlab  
installation is probably broken.


  More news: the root of this issue is ItemDocument, which seems to  
register UIDs, and fails to unregister them -- even if there is no item  
associated to that UID. I've comitted in the 0.3.7 branch a fix which  
unregisters the UID of the connector right before creating the connector.  
Now the bug had disappeared, and I hope it didn't create other bugs.  
Please test it. :)

  Zoltan

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/XcvMzF8H">http://p.sf.net/sfu/XcvMzF8H</a>
_______________________________________________
Ktechlab-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ktechlab-devel@...>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a>

  </pre>
</blockquote>
I just Checked out revision 204, and still have the same problem, just
not as bad. Am I getting it from the wrong place?<br>
</body>
</html>

On Tuesday 17 February 2009 19:48:21 P Zoltan wrote:
>   More news: the root of this issue is ItemDocument, which seems to
> register UIDs, and fails to unregister them -- even if there is no item
> associated to that UID. I've comitted in the 0.3.7 branch a fix which
> unregisters the UID of the connector right before creating the connector.
> Now the bug had disappeared, and I hope it didn't create other bugs.
> Please test it. :)

Runs fine with my tests. I added a warning if a connector with this id already 
exists. May be this helps finding any glitches you introduced. If anybody 
mentions an issue, we could find out, which id is involved.

I also will apply this patch to trunk for now, since we run into the same 
problems there ;) It can be reverted if we find a better solution, but for now 
it's the only thing, we got.... ;)

bye
julian

On Tue, 17 Feb 2009 22:17:24 +0100, Lawrence Shafer <detroit371@...>  
wrote:

>
> I just Checked out revision 204, and still have the same problem, just  
> not as
> bad. Am I getting it from the wrong place?

  Try (any) branch after rev. 208.