When I process the following file with dot (version 2.38.0), I get a Warning: Arrow type "fooo" unknown - ignoring.
digraph {
n1 [ label="ND 1" ];
n5 [ label="ND 5" ];
n12 [
label=<
<table>
<tr>
<td port='fooo'>FOOOOOO</td>
</tr>
</table>>
];
n12:fooo -> n1;
n5 -> n1 [arrowhead=invempty];
{rank=same; n1 n12}
}
I am unable to figure out, why that is.
When I remove either the n5 -> n1 [arrowhead=invempty]; or the {rank=same; n1 n12} statement, the warning goes away.
Can someone explain this to me?
It just doesn't like your port='fooo' attribute, as that is not a defined alternative for port. Even though the documentation suggests that an ID is okay there, replacing fooo with e (from the list of available "compass point" options) gives a good result:
digraph {
n1 [ label="ND 1" ];
n5 [ label="ND 5" ];
n12 [ label=<<table><tr><td port='e'>FOOOOOO</td></tr></table>> ];
n12:e -> n1;
n5 -> n1 [arrowhead="invempty"];
{rank=same; n1 n12}
}
with no warnings of any kind. This is puzzling because the documentations states that port:':' ID [ ':' compass_pt ] is valid, suggesting that compass point is optional but that ID is not. Your example suggests otherwise.
Related
I want to extract points from line feature from shapefile.
I have search for solutions, it shows that most of people use gis:vertex-lists-of to do this.
For example,
However I got an error message below when I try to do that:
Extension exception: not a VectorFeature:
org.myworldgis.netlogo.VectorDataset#ca24265
error while observer running GIS:VERTEX-LISTS-OF
called by procedure DRAW-CITIES
called by Button 'draw-cities'
Code below:
to draw-cities
gis:set-drawing-color red
gis:draw cities-dataset 1
foreach gis:vertex-lists-of cities-dataset [
a ->
]
end
cities-dataset is a points collection shapefile from Netlogo library ""GIS general examples" model
I don't understand that even I put a points feature in the function, I just got an error.
Do I misuse the function? How can I corectly use it? Thank you.
The reason for the error is because your foreach function is missing the action steps a foreach function looks something like this:
foreach [1 2 3][a -> print a + 1]
If you wanted to do something like the code you linked to then it would look like this:
extensions [ gis ]
globals [ cities-dataset]
breed [ cities city ]
breed [nodes node]
cities-own [ name country population ]
to setup
set cities-dataset gis:load-dataset "C:/Program Files/NetLogo 6.2.2/app/models/Code Examples/Extensions Examples/gis/data/cities.shp"
draw-cities
end
to draw-cities
gis:set-drawing-color red
gis:draw cities-dataset 1
foreach gis:feature-list-of cities-dataset[
i ->
foreach gis:vertex-lists-of i[
j ->
let first-node-point nobody
let previous-node-point nobody
foreach j [
k ->
let location gis:location-of k
if not empty? location [
ifelse any? nodes with [
xcor = item 0 location and ycor = item 1 location
]
[]
[
create-nodes 1[
set xcor item 0 location
set ycor item 1 location
set size 0.23
set shape "circle"
set color 23
set hidden? false
]
]
;to create links
let node-here (nodes with [
xcor = item 0 location and ycor = item 1 location
])
ifelse previous-node-point = nobody
[set first-node-point node-here]
[let who-node 0
let who-prev 0
ask node-here
[create-link-with previous-node-point
set who-node who]
ask previous-node-point[
set who-prev who
]
set previous-node-point one-of node-here
]
]
]
]
]
end
I'm not entirely sure what you're looking to do, but feel free to ask for more help.
Let us consider a tcl data as follows:
set arr {a {{c 1} {d {2 2 2} e 3}} b {{f 4 g 5}}}
Converted into Json format using huddle module:
set json_arr [huddle jsondump [huddle compile {dict * {list {dict d list}}} $arr]]
puts $json_arr
Json fromatted array:
{
"a": [
{"c": 1},
{
"d": [
2,
2,
2
],
"e": 3
}
],
"b": [{
"f": 4,
"g": 5
}]
}
Writing in a single line:
set json_arr [huddle jsondump [huddle compile {dict * {list {dict d list}}} $arr] {} {}]
puts $json_arr
Updated Json formatted array:
{"a":[{"c":1},{"d":[2,2,2],"e":3}],"b":[{"f":4,"g":5}]}
What is the meaning of {} {} here?
Can I use the same for single line in case of output by json and json::write module ?
The last three, optional, arguments to jsondump are offset, newline, and begin_offset. You can use those to specify strings that are to be used to format the output string. If you don’t specify them, default strings will be used.
If you do specify them, you need to follow the protocol for optional arguments, i.e. if you want to specify begin_offset, you need to specify offset and newline too, etc. In this case, offset and newline are specified to be empty strings, and begin_offset uses its default value.
Try invoking jsondump with dummy values to get an idea of how they are used:
% huddle jsondump [huddle compile {dict * {list {dict d list}}} $arr] <A> <B> <C>
{<B><C><A>"a": [<B><C><A><A>{"c": 1},<B><C><A><A>{<B><C><A><A><A>"d": [<B><C><A><A><A><A>2,<B><C><A><A><A><A>2,<B><C><A><A><A><A>2<B><C><A><A><A>],<B><C><A><A><A>"e": 3<B><C><A><A>}<B><C><A>],<B><C><A>"b": [{<B><C><A><A><A>"f": 4,<B><C><A><A><A>"g": 5<B><C><A><A>}]<B><C>}
A newline and a begin_offset string is inserted around each component, and one or more offset strings are inserted before a component to reflect the indentation level.
json::write uses the indented and aligned subcommands to customize formatting.
We can access any JSON element in PostgreSQL 9.3 using the -> and ->> operators. Seems to me that the #> along with #>> only provide a shorter form of writing the JSON path. Or is there a bigger picture behind the #> operator? Does it serve a special purpose/provide any advantage over the arrow notation? Which one is the preffered method of writing paths?
It all comes to the question: why should I use the #> and #>> operator over the -> and ->>?
The docs are a bit enigmatic about this.
Both queries below give the same result:
=> select '{"a":[1,2,3],"b":[4,5,6]}'::json#>'{a,2}';
?column?
----------
3
=> select '{"a":[1,2,3],"b":[4,5,6]}'::json->'a'->>2;
?column?
----------
3
Consider nesting.
{
"a" : {
"b" : {
"c" : 1,
"d" : 2
}
}
}
Imagine that you have a json document, and you don't know in advance how it will be nested. If you knew you needed a three level path, you could write:
SELECT '{
"a" : {
"b" : {
"c" : 1,
"d" : 2
}
}
}'::json -> 'a' -> 'b' -> 'c';
but what if you want to write a query that doesn't know that in advance? That's where the path-based operators are useful; the path can be supplied along with the document, and there's no longer any assumption about the document structure in the query.
SELECT '{
"a" : {
"b" : {
"c" : 1,
"d" : 2
}
}
}'::json #>> ARRAY['a','b','c']
I'm using QuickGraph to create a graph of (P)roducts and the properties associated in them, (T)ype, (S)ubtype and (F)requency.
So in this example, I have 2 products P1 & P2:
P1 is assigned properties T1, S1 & S2, F1
P2 is assigned properties T1, S1, F1 & F2
The directed, unweighted graph looks like this:
Is there any way to use this generate a JSON object to hold the full paths to all products? Something like:
{T1: [
{S1: [
{F1: [
P1,P2
]},
{F2: [
P2
]}
]},
{S2: [
{F1: [
P1
]}
]}
]}
I initially looked at DepthFirstSearchAlgorithm and its DiscoverVertex event, which will walk the graph by depth but the this event is only triggered when a new vertex is discovered so I get T1,S1,F1,P1,P2,F2,S2.
Any help appreciated.
I have reduced down to a small example some code that I have, which tests for whether a variable called class-name has a value assigned to it:
ask-params: function [
config-file [file!]
default-class-name
default-fields
] [
probe value? 'class-name
input
either (value? 'class-name) [
probe class-name
] [
;-- omit code in this branch for now
]
]
ret-block: ask-params %simple-class.params.txt "Person" "First Name, Last Name"
The expression value? 'class-name returns false here. On the other hand, if I fill in the missing branch with an assignment:
ask-params: function [
config-file [file!]
default-class-name
default-fields
] [
probe value? 'class-name
input
either (value? 'class-name) [
probe class-name
] [
class-name: default-class-name
]
]
ret-block: ask-params %simple-class.params.txt "Person" "First Name, Last Name"
This will return true for value? 'class-name. But in this second case, class-name: default-class-name isn't even executed yet.
I would think that class-name shouldn't exist in memory, so value? 'class-name should be returning false. Why is value? returning true instead?
You are using function. This scans the body of the function and pre-creates the local variables for you, initialized to NONE. That's why value? 'class-name becomes true (because NONE is a legal value for a variable, distinct from the situation of being "unset").
If you used func instead, then both would return false.
I don't think function behaves differently than func /local. Look at these examples:
>> f: func [/x] [value? 'x]
>> f
== true
I didn't give any value to x, but it says it HAS a value. Same for /local
>> f: func [/local x] [value? 'x]
>> f
== true
Because when you make a variable local (or a refinement) then it means you already set a value for it (which is none) and that is what function does.
Here I show you two examples not using FUNCTION, but otherwise equivalent to your code:
ask-params: func [config-file [file!] default-class-name default-fields] [
probe value? 'class-name
input
either (value? 'class-name) [
probe class-name
][
]
]
ask-params: func [
config-file [file!] default-class-name default-fields /local class-name
] [
probe value? 'class-name
input
either (value? 'class-name) [
probe class-name
][
]
]
While the value? function in the first example yields #[false], in the second example it yields #[true]. That is because the "refinement arguments" following an "unused refinement" (a refinement that is not used in the actual call) are initialized to #[none!] together with the refinement variable. This applies to the /local variables as well, since the /local refinement does not differ from other function refinements (except for the fact, that it is a convention to use it to define local variables).
Since the function generator uses the /local method to implement local variables "under the hood", the above description applies to all functions it generates as well.
There is another way, which avoids using FUNC/LOCAL and still allows the use of FUNCTION.
That is to not use a SET-WORD! for the assignment. Instead use the SET function on a LIT-WORD!
ask-params: function [config-file [file!] default-class-name default-fields] [
probe value? 'class-name
input
either (value? 'class-name) [
probe class-name
] [
set 'class-name default-class-name
]
]
You will get #[false] for the value? function. However, the call to SET will be setting class-name in the global environment...not as a local.