From gambas at ...1... Thu Jul 10 23:18:51 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Thu, 10 Jul 2014 23:18:51 +0200 Subject: [Gambas-devel] Fwd: Re: "Overriding" virtual classes In-Reply-To: <53BF0320.1010709@...1...> References: <53BF0320.1010709@...1...> Message-ID: <53BF033B.6060205@...1...> > On Mon, 23 Jun 2014, Tobias Boege wrote: >> A try will show how far I can get with the solution I just sent in another >> mail. If it's not satisfying, I'll return to this thread... >> > > I have almost all pieces collected. But take this sample expression (first > the variable/property/method name, then the class name in parentheses): > > myGraph (Graph) > `-- .Vertices (.Graph.Enumerable) > `-- [iVertex] (.Graph.Vertex) > `-- .OutEdges (.Graph.Enumerable) > > This expression may be used as > > Dim iEdge As Integer > > For Each iEdge In myGraph.Vertices[iVertex].OutEdges > Print "The vertex";; myGraph.Edges[iEdge].Destination;; "is adjacent to";; iVertex > Next > > This way, I have lots of different classes that inherit .Graph.Enumerable > which is just a class that has a _next() method. But this _next() method > needs to be implemented differently for different things to enumerate on a > graph, like vertices, edges or edges going out from a particular vertex. > > You see, there is lots of things to be enumerated here and my problem is > that I don't want users to have like a half dozen (Graph.Vertices, > Graph.Edges, Graph.Vertices[i].InEdges, Graph.Vertices[i].OutEdges, > Graph.Vertices[i].Adjacent) classes to write which all just contain _next() > methods. (On the other hand, I do want to use virtual classes instead of > arrays to reduce memory usage for graphs that are implicitly defined by > another data structure (for which I gave an example yesterday).) > > I thought of having like _nextVertex() and _nextEdge() methods in the > *Graph* class. Then I could write a .Graph.Vertices class which Inherits > .Graph.Enumerable and is responsible for iterating over the vertices of a > graph - once and for all in gb.data. No Gambas programmer would then have to > write their own .Graph.Enumerable class for vertices (and likewise with the > other enumerable things). > > Its _next() method would only consist of a call to the _nextVertex() method > of the concrete Graph implementation. This way, we can preserve the syntax > > Dim iVertex As Integer > > For Each iVertex in myGraph.Vertices > ' ... > Next > > But there is the overhead of the call to myGraph._nextVertex() from > .Graph.Vertices._next(), i.e. GB.GetFunction() and GB.Call() because the > actual Graph's _nextVertex() implementation or location is unknown at > compilation time. > > The goal is, as I said, to reduce the number of short classes the user has > to write to implements their own Graph. In Java, the situation is a bit > better because there you can have nested classes which are easier to read > because they're *inside* the class they operate on and can also access their > private symbols. > > Do you have a better idea? What I need is a way to iterate over the same > object in multiple ways, i.e. I need For-Each to be able to pick different > _next() implementations in the same class. > > Regards, > Tobi > 1) Can you commit your code? 2) Do you want the user to implement its own graph class in Gambas or in C/C++? -- Beno?t Minisini From tobias at ...692... Thu Jul 10 23:32:46 2014 From: tobias at ...692... (Tobias Boege) Date: Thu, 10 Jul 2014 23:32:46 +0200 Subject: [Gambas-devel] Fwd: Re: "Overriding" virtual classes In-Reply-To: <53BF033B.6060205@...1...> References: <53BF0320.1010709@...1...> <53BF033B.6060205@...1...> Message-ID: <20140710213246.GD528@...693...> On Thu, 10 Jul 2014, Beno?t Minisini wrote: > > On Mon, 23 Jun 2014, Tobias Boege wrote: > >> A try will show how far I can get with the solution I just sent in another > >> mail. If it's not satisfying, I'll return to this thread... > >> > > > > I have almost all pieces collected. But take this sample expression (first > > the variable/property/method name, then the class name in parentheses): > > > > myGraph (Graph) > > `-- .Vertices (.Graph.Enumerable) > > `-- [iVertex] (.Graph.Vertex) > > `-- .OutEdges (.Graph.Enumerable) > > > > This expression may be used as > > > > Dim iEdge As Integer > > > > For Each iEdge In myGraph.Vertices[iVertex].OutEdges > > Print "The vertex";; myGraph.Edges[iEdge].Destination;; "is adjacent to";; iVertex > > Next > > > > This way, I have lots of different classes that inherit .Graph.Enumerable > > which is just a class that has a _next() method. But this _next() method > > needs to be implemented differently for different things to enumerate on a > > graph, like vertices, edges or edges going out from a particular vertex. > > > > You see, there is lots of things to be enumerated here and my problem is > > that I don't want users to have like a half dozen (Graph.Vertices, > > Graph.Edges, Graph.Vertices[i].InEdges, Graph.Vertices[i].OutEdges, > > Graph.Vertices[i].Adjacent) classes to write which all just contain _next() > > methods. (On the other hand, I do want to use virtual classes instead of > > arrays to reduce memory usage for graphs that are implicitly defined by > > another data structure (for which I gave an example yesterday).) > > > > I thought of having like _nextVertex() and _nextEdge() methods in the > > *Graph* class. Then I could write a .Graph.Vertices class which Inherits > > .Graph.Enumerable and is responsible for iterating over the vertices of a > > graph - once and for all in gb.data. No Gambas programmer would then have to > > write their own .Graph.Enumerable class for vertices (and likewise with the > > other enumerable things). > > > > Its _next() method would only consist of a call to the _nextVertex() method > > of the concrete Graph implementation. This way, we can preserve the syntax > > > > Dim iVertex As Integer > > > > For Each iVertex in myGraph.Vertices > > ' ... > > Next > > > > But there is the overhead of the call to myGraph._nextVertex() from > > .Graph.Vertices._next(), i.e. GB.GetFunction() and GB.Call() because the > > actual Graph's _nextVertex() implementation or location is unknown at > > compilation time. > > > > The goal is, as I said, to reduce the number of short classes the user has > > to write to implements their own Graph. In Java, the situation is a bit > > better because there you can have nested classes which are easier to read > > because they're *inside* the class they operate on and can also access their > > private symbols. > > > > Do you have a better idea? What I need is a way to iterate over the same > > object in multiple ways, i.e. I need For-Each to be able to pick different > > _next() implementations in the same class. > > > > Regards, > > Tobi > > > > 1) Can you commit your code? > It's not really done yet (and by "it" I mean just the interface). It's the examination period currently for me, so I will take entire days off to work on Gambas but afterwards entire weeks to prepare. Tomorrow noon, I'll begin a Gambas day again and can hopefully incorporate the suggestions from gambas-user into my mind map :-) > 2) Do you want the user to implement its own graph class in Gambas or in > C/C++? > In Gambas! I succeeded to implement a Graph which is implicitly defined by an Image object (in pure Gambas), by inheriting native virtual classes (with the _Virtual_ClassName naming scheme, i.e. with underscores instead of dots, so that the appropriate source files can actually be created and used in Gambas code). I'll commit tomorrow, I hope. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From tobias at ...692... Thu Jul 10 23:32:46 2014 From: tobias at ...692... (Tobias Boege) Date: Thu, 10 Jul 2014 23:32:46 +0200 Subject: [Gambas-devel] Fwd: Re: "Overriding" virtual classes In-Reply-To: <53BF033B.6060205@...1...> References: <53BF0320.1010709@...1...> <53BF033B.6060205@...1...> Message-ID: <20140710213246.GD528@...693...> On Thu, 10 Jul 2014, Beno?t Minisini wrote: > > On Mon, 23 Jun 2014, Tobias Boege wrote: > >> A try will show how far I can get with the solution I just sent in another > >> mail. If it's not satisfying, I'll return to this thread... > >> > > > > I have almost all pieces collected. But take this sample expression (first > > the variable/property/method name, then the class name in parentheses): > > > > myGraph (Graph) > > `-- .Vertices (.Graph.Enumerable) > > `-- [iVertex] (.Graph.Vertex) > > `-- .OutEdges (.Graph.Enumerable) > > > > This expression may be used as > > > > Dim iEdge As Integer > > > > For Each iEdge In myGraph.Vertices[iVertex].OutEdges > > Print "The vertex";; myGraph.Edges[iEdge].Destination;; "is adjacent to";; iVertex > > Next > > > > This way, I have lots of different classes that inherit .Graph.Enumerable > > which is just a class that has a _next() method. But this _next() method > > needs to be implemented differently for different things to enumerate on a > > graph, like vertices, edges or edges going out from a particular vertex. > > > > You see, there is lots of things to be enumerated here and my problem is > > that I don't want users to have like a half dozen (Graph.Vertices, > > Graph.Edges, Graph.Vertices[i].InEdges, Graph.Vertices[i].OutEdges, > > Graph.Vertices[i].Adjacent) classes to write which all just contain _next() > > methods. (On the other hand, I do want to use virtual classes instead of > > arrays to reduce memory usage for graphs that are implicitly defined by > > another data structure (for which I gave an example yesterday).) > > > > I thought of having like _nextVertex() and _nextEdge() methods in the > > *Graph* class. Then I could write a .Graph.Vertices class which Inherits > > .Graph.Enumerable and is responsible for iterating over the vertices of a > > graph - once and for all in gb.data. No Gambas programmer would then have to > > write their own .Graph.Enumerable class for vertices (and likewise with the > > other enumerable things). > > > > Its _next() method would only consist of a call to the _nextVertex() method > > of the concrete Graph implementation. This way, we can preserve the syntax > > > > Dim iVertex As Integer > > > > For Each iVertex in myGraph.Vertices > > ' ... > > Next > > > > But there is the overhead of the call to myGraph._nextVertex() from > > .Graph.Vertices._next(), i.e. GB.GetFunction() and GB.Call() because the > > actual Graph's _nextVertex() implementation or location is unknown at > > compilation time. > > > > The goal is, as I said, to reduce the number of short classes the user has > > to write to implements their own Graph. In Java, the situation is a bit > > better because there you can have nested classes which are easier to read > > because they're *inside* the class they operate on and can also access their > > private symbols. > > > > Do you have a better idea? What I need is a way to iterate over the same > > object in multiple ways, i.e. I need For-Each to be able to pick different > > _next() implementations in the same class. > > > > Regards, > > Tobi > > > > 1) Can you commit your code? > It's not really done yet (and by "it" I mean just the interface). It's the examination period currently for me, so I will take entire days off to work on Gambas but afterwards entire weeks to prepare. Tomorrow noon, I'll begin a Gambas day again and can hopefully incorporate the suggestions from gambas-user into my mind map :-) > 2) Do you want the user to implement its own graph class in Gambas or in > C/C++? > In Gambas! I succeeded to implement a Graph which is implicitly defined by an Image object (in pure Gambas), by inheriting native virtual classes (with the _Virtual_ClassName naming scheme, i.e. with underscores instead of dots, so that the appropriate source files can actually be created and used in Gambas code). I'll commit tomorrow, I hope. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From gambas at ...1... Fri Jul 11 20:09:52 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Fri, 11 Jul 2014 20:09:52 +0200 Subject: [Gambas-devel] Fwd: Re: "Overriding" virtual classes In-Reply-To: <20140710213246.GD528@...693...> References: <53BF0320.1010709@...1...> <53BF033B.6060205@...1...> <20140710213246.GD528@...693...> Message-ID: <53C02870.1050508@...1...> Le 10/07/2014 23:32, Tobias Boege a ?crit : >> >> 1) Can you commit your code? >> > > It's not really done yet (and by "it" I mean just the interface). It's the > examination period currently for me, so I will take entire days off to work > on Gambas but afterwards entire weeks to prepare. > > Tomorrow noon, I'll begin a Gambas day again and can hopefully incorporate > the suggestions from gambas-user into my mind map :-) > >> 2) Do you want the user to implement its own graph class in Gambas or in >> C/C++? >> > > In Gambas! I succeeded to implement a Graph which is implicitly defined by > an Image object (in pure Gambas), by inheriting native virtual classes (with > the _Virtual_ClassName naming scheme, i.e. with underscores instead of dots, > so that the appropriate source files can actually be created and used in > Gambas code). I'll commit tomorrow, I hope. > > Regards, > Tobi > Maybe you should do differently, like I did to implement the Paint class. 1) You implement only one set of classes, but they use an internal "graph" interface that is just a structure of function pointers that do the real job you need. See 'cpaint_impl.cpp' in 'gb.qt4/src' for the syntax of the interface, and 'CImage.cpp' to see how I declare using it in the Image class. 2) Then you must handle the special case of a Graph interface written in Gambas, by making a dedicated interface that just calls the Gambas functions, and an option to tell that you are using a Gambas class as interface, and not a native one. You have something like that with the highlighting method of the Editor class. If you want to highlight Gambas code, an internal C function is called. Otherwise a Gambas function is called. Maybe I was not very clear, but you will ask me! Regards, -- Beno?t Minisini From tobias at ...692... Sat Jul 12 02:30:58 2014 From: tobias at ...692... (Tobias Boege) Date: Sat, 12 Jul 2014 02:30:58 +0200 Subject: [Gambas-devel] [Gambas-devel-svn] SF.net SVN: gambas:[6372] gambas/trunk/main/lib/data In-Reply-To: References: Message-ID: <20140712003058.GG1318@...693...> On Sat, 12 Jul 2014, tobiasboe at ...1... wrote: > Revision: 6372 > http://sourceforge.net/p/gambas/code/6372 > Author: tobiasboe > Date: 2014-07-12 00:20:35 +0000 (Sat, 12 Jul 2014) > Log Message: > ----------- > [GB.DATA] > * NEW: First attempt to define a Graph class interface > @Benoit: I haven't read the Paint/Image classes yet you proposed. I thought maybe I should just commit to let you see what I did. The virtual classes approach works by: (1) Define a virtual class property to mean something, like Graph.Vertices, virtual of type .Graph.Vertices to enumerate vertices. (2) In .Graph.Vertices, define _next() to call a hidden method _nextVertex() which is implemented in the real Graph class. This minimises the amount of classes one has to write because everything can get into Graph or the _Graph_Vertex class (we have a total of 5 enumerable classes merged this way into these both classes). I attach a project which implements a Graph over an Image object which can be flood-filled by the BFS algorithm. The interesting source files would be in ImageGraph/. In the GUI, you have a minimal ColorChooser type of control on the right side. Just select a color and then click on the Image to start the flood- fill at the pixel you pointed to. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk -------------- next part -------------- A non-text attachment was scrubbed... Name: GraphFloodfill-0.1.tar.gz Type: application/octet-stream Size: 7721 bytes Desc: not available URL: From tobias at ...692... Sun Jul 13 19:43:54 2014 From: tobias at ...692... (Tobias Boege) Date: Sun, 13 Jul 2014 19:43:54 +0200 Subject: [Gambas-devel] [Gambas-devel-svn] SF.net SVN: gambas:[6374] gambas/trunk In-Reply-To: References: Message-ID: <20140713174354.GA657@...693...> On Sun, 13 Jul 2014, gambas at ...1... wrote: > [GB.DESKTOP] > * NEW: Desktop.NetworkAvailable is a new property that returns if the > network is available. It just use 'ifconfig' to search for a network > interface having an IP address different from '127.0.0.1' The distributions I lookied at recently all came without "ifconfig" but with the "ip" program instead. Maybe we should consider this alternative setup. If it helps you to implement it: $ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet xxx.xx.xxx.xx/xx brd xxx.xx.xxx.xxx scope global eth0 valid_lft forever preferred_lft forever inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link valid_lft forever preferred_lft forever To extract the IP addresses of all interfaces: $ ip addr | egrep -o "inet [^/]+" | sed 's/inet \(.*\)/\1/' 127.0.0.1 xxx.xx.xxx.xx Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk From gambas at ...1... Sun Jul 13 19:48:27 2014 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 13 Jul 2014 19:48:27 +0200 Subject: [Gambas-devel] [Gambas-devel-svn] SF.net SVN: gambas:[6374] gambas/trunk In-Reply-To: <20140713174354.GA657@...693...> References: <20140713174354.GA657@...693...> Message-ID: <53C2C66B.7080105@...1...> Le 13/07/2014 19:43, Tobias Boege a ?crit : > On Sun, 13 Jul 2014, gambas at ...1... wrote: >> [GB.DESKTOP] >> * NEW: Desktop.NetworkAvailable is a new property that returns if the >> network is available. It just use 'ifconfig' to search for a network >> interface having an IP address different from '127.0.0.1' > > The distributions I lookied at recently all came without "ifconfig" but > with the "ip" program instead. Maybe we should consider this alternative > setup. If it helps you to implement it: > > $ ip addr > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 > link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff > inet xxx.xx.xxx.xx/xx brd xxx.xx.xxx.xxx scope global eth0 > valid_lft forever preferred_lft forever > inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link > valid_lft forever preferred_lft forever > > To extract the IP addresses of all interfaces: > > $ ip addr | egrep -o "inet [^/]+" | sed 's/inet \(.*\)/\1/' > 127.0.0.1 > xxx.xx.xxx.xx > > Regards, > Tobi > I didn't know. Thanks, I will take that into account. -- Beno?t Minisini From gambas.fr at ...176... Sun Jul 13 21:18:17 2014 From: gambas.fr at ...176... (Fabien Bodard) Date: Sun, 13 Jul 2014 21:18:17 +0200 Subject: [Gambas-devel] [Gambas-devel-svn] SF.net SVN: gambas:[6374] gambas/trunk In-Reply-To: <53C2C66B.7080105@...1...> References: <20140713174354.GA657@...693...> <53C2C66B.7080105@...1...> Message-ID: It don't work here ... the internet connection is not detected. [fabien at ...738... gambas]$ ifconfig eth0: flags=4099 mtu 1500 ether 54:04:a6:27:bf:2c txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4163 mtu 1500 inet 192.168.1.97 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::762f:68ff:fed8:48ea prefixlen 64 scopeid 0x20 ether 74:2f:68:d8:48:ea txqueuelen 1000 (Ethernet) RX packets 692527 bytes 961922724 (917.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 512635 bytes 53538712 (51.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 2014-07-13 19:48 GMT+02:00 Beno?t Minisini : > Le 13/07/2014 19:43, Tobias Boege a ?crit : >> On Sun, 13 Jul 2014, gambas at ...1... wrote: >>> [GB.DESKTOP] >>> * NEW: Desktop.NetworkAvailable is a new property that returns if the >>> network is available. It just use 'ifconfig' to search for a network >>> interface having an IP address different from '127.0.0.1' >> >> The distributions I lookied at recently all came without "ifconfig" but >> with the "ip" program instead. Maybe we should consider this alternative >> setup. If it helps you to implement it: >> >> $ ip addr >> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> inet 127.0.0.1/8 scope host lo >> valid_lft forever preferred_lft forever >> inet6 ::1/128 scope host >> valid_lft forever preferred_lft forever >> 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 >> link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff >> inet xxx.xx.xxx.xx/xx brd xxx.xx.xxx.xxx scope global eth0 >> valid_lft forever preferred_lft forever >> inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link >> valid_lft forever preferred_lft forever >> >> To extract the IP addresses of all interfaces: >> >> $ ip addr | egrep -o "inet [^/]+" | sed 's/inet \(.*\)/\1/' >> 127.0.0.1 >> xxx.xx.xxx.xx >> >> Regards, >> Tobi >> > > I didn't know. Thanks, I will take that into account. > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel -- Fabien Bodard From gambas at ...1... Sun Jul 13 21:52:21 2014 From: gambas at ...1... (=?UTF-8?B?QmVub8OudCBNaW5pc2luaQ==?=) Date: Sun, 13 Jul 2014 21:52:21 +0200 Subject: [Gambas-devel] [Gambas-devel-svn] SF.net SVN: gambas:[6374] gambas/trunk In-Reply-To: References: <20140713174354.GA657@...693...> <53C2C66B.7080105@...1...> Message-ID: <53C2E375.9050504@...1...> Le 13/07/2014 21:18, Fabien Bodard a ?crit : > It don't work here ... the internet connection is not detected. > Try with revision #6377, and tell me... -- Beno?t Minisini