After spending a bunch of time with the graphviz utilities (neato, dot, circo and twopi) trying to create a graph to understand the software dependencies between modules in a project I’ve been I assigned I realized that those tools don’t work well with large graphs. I tried and tried with no luck, I thought that the old linux kernel map poster used graphviz to create the poster but after googling a bit and reading the code for the FCGP project I found that they write PostScript directly. I was looking for something simpler.
After giving up with graphviz I found a bunch of tools for working with graphs most of them are toolkits to develop your own tools but then I hit GUESS. GUESS is a graph browser so to say. You generate a .gdf similar to graphviz’s .dot files and GUESS will layout the graph for you. But the really good thing is that it is a browser you can actually interact with the graph, changing the layout or coloring items, etc. It comes with a scripting language that allow to manipulate the graph very easily and to neat things like change the size of the nodes depending on the value of certain field of the node. All this in runtime. So if you wan to spot all the nodes in your graph where the field “module” is equal to “provisioning” you just enter this in the console
selectednodes = (module == "provisioning)
selectednode.color = red
Every time I run setup.exe and try to upgrade bash package
setup.exe crashes with the familiar “setup.exe has generated errors and will be close by windows. you will need to restart the program. An error log is being created”. The solution I found is for bash package but I guess it also work for other packages as well
After googling a bit I found the this mail thread . But there was no solution posted into the thread so I tried to contact the Mario Frasca (one of the participants in the mail thread) to see if he found any solution to the problem. Well, he did. He sent me a mail telling me that William Crosmun resolved his problem.
It seems that /etc/setup/bash.lst.gz became corrupted.
and if you delete it
and retry the upgrade now everything should work.
UPDATE: Please make a backup of the file before deleting it. If deleting the file solve the issue then please fill a bug report at cygwin and include that file. Or post a comment here and I will try to take care of it.
Hope it helps. Remember that if your setup.exe crashes while upgrading a package other than bash you should try to delete otherpackage.lst.gz instead of bash.lst.gz.
EDIT: to find the offending package you can use for i in $(ls /etc/setup/*.gz); do gunzip -t $i; done as stated in the comments.
It’s not easy to get information on derby keys once you created them. I was looking for a command like “SHOWCREATETABLE” but no luck. I realized that the answer should lay in SYS tables. After googling a while I found the following bit of wisdom:
The following query will give you the UNIQUE constraints on a table:
select c.constraintname, c.constraintid
from sys.systables t, sys.sysconstraints c
where t.tablename = ‘FOO’
and t.tableid = c.tableid
and c.type = ‘U’;
The following query will return a descriptor object for each constraint
on the table. The descriptor will tell you which columns are in each
constraint. As noted in the Reference Guide section on SYS.SYSCONGLOMERATES, the descriptor object implements
org.apache.derby.catalog.IndexDescriptor. Please note that the
descriptor object is not part of Derby’ public API and can therefore
change from release to release:
I just realized that to be able to open/share the same Derby database from two different web applications running in the same Tomcat instance (same JVM) you’ll need to put derby.jar in the $TOMCAT_HOME/common/lib and remove it from your applications WEB-INF/lib. I got the clue from this RIFE web page
the jarfiles you need are derby.jar and derbytools.jar . Due to classloader peculiarities, don’t copy them to your application’s web/WEB-INF/lib/ subdirectory, or to Tomcat’s shared/lib/ directory. Tomcat’s common/lib/ directory works, and probably common/endorsed/ does too.
I’ve been trying to use XStream to generate JSONto be consumed by Dojo. But I can’t find the way to generate the right JSON from XStream, it keeps adding extraneous {} around. I even tried this but no luck . For example I want to generate this JSON output (taken from Dojo FilteringSelect example) :
I couldn’t figure out how to get XStream to output the desired JSON. The main issue is that I couldn’t make “items” a simple JSON array, it always end up as an object with an array in it. So I decided to give out a try to FLEXJSON. I really found much easier to control the output with this tool. I guess that XStream is more focused on serialization/deserialization and doesn’t allow customization without relaying in custom converters (I didn’t walk that road, too much work). Here is the example source code (also as a gist) using FLEXJSON:
If your are getting “bash: clear: command not found” on you first install of cygwin you have to make sure that you include ncurses packages in your cygwin installation. clear.exe doesn’t come in the standard installation. You must include ncurses to get clear.exe in your system. If you are using bash you can use Ctrl-L and get the same result though.
UPDATE: ncurses is a cygwin package in libs category in Utils category. You can install it using the the Cygwin Setup utility (just run setup.exe again). See screenshot below
You probably found that it didn’t work. The browser will end up in an endless loop of redirections. Firefox will complain with this error message:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.
The right way to accomplish the root to subfolder redirection is the following:
I’ve submitted a patch (Attachment #77777 and a couple of screenshots ( Attachment #77774 y Attachment #77776) to Bug #201116. It’s only a preliminary work but it enables the user to select with contentMergeViewer to use with each FileType/ContentType. Now it’s only useful if you use my java formatting compare plugin. Currently the org.eclipse.compare subsystem will allow only one contentMergeViewer per fileType or contentType and you cannot tell which one it will be as Szymon Brandys comments. With this patch the user can select/switch which one he wants to use among all viewer registered for a given file extension/content type.