Netlogo transition, backwards compatibility - transition

'd like to upgrade (if that's the word) a 100-150 of home-grown Netlogo 4.1.3 programs to Netlogo 6, preferably in batch by means of Perl or another scripting language, followed by a (necessary) manual inspection and finish.
To my dismay Netlogo 6 won't open Netlogo 4 files, so I've upgraded a few of them by opening them in Netlogo 5, save and reopen in Netlogo 6 and save. Not a particularly elegant way.
Any advice?.

It looks like the reason Netlogo 6 won't read the 4.1.3 files is that it expects 12 sections, whereas the 4.1.3 files have 10 or 11. As far as I can tell, sections are broken up by the string "##$###$##". Additionally, older .nlogo files had parameters for a "CC-WINDOW" that version 6 does not understand. Finally, buttons in Netlogo 6 also need to be parameterized with a value of 1 or 0 to determine whether that button is disabled until ticks start or not.
The following python 3 code takes all Netlogo files in the same folder and cuts out the "CC-WINDOW" lines. It also adds a 1 to the end of every "Button" block. As the code reads the file, it counts the number of "##$###$##" breaks. If at the end of the file, there are fewer than 11, it appends enough "##$###$##" breaks to make the total 11.
If you want to run this code, I would copy the old files you want to update into a new folder. Place the .py file with the following code into that same folder, and when you run it it will create new files for the 6.0 compatible versions (Note that it will not only update the 4.1.3 files, but any netlogo files in that folder). This doesn't work for every file- for example, one file did not update correctly because the original model's "GRAPHICS-WINDOW" was not properly parameterized. That said, this code worked for the majority of the 4.1.3 model library models that I tested. Also, I only know that it allows you to open the files in Netlogo 6, I don't know what will have to be done after that to make sure that the models actually run as you would expect.
Hopefully that helps! Let me know if I was not clear on some point.
import os
with open("files_updated.txt", "w") as files:
for filename in os.listdir("."):
if filename.endswith(".nlogo") and not filename.startswith("6"):
files.write(filename + '\n')
opened = open(filename, "r")
n = 0
printat = -1
cut_count = 0
count_breakers = 0
new_file_name = ("6_"+filename.strip(".txt") + ".nlogo")
print(new_file_name)
with open(new_file_name, "w") as out:
for line in opened:
n += 1
if line == "##$###$##\n":
count_breakers += 1
if line == "CC-WINDOW\n":
cut_count = 8
cut_count -= 1
if cut_count < 0:
out.write(line)
if line == "BUTTON\n" :
printat = n + 14
if printat == n:
out.write("1\n")
if count_breakers < 11:
out.write("##$###$##\n" * (11 - count_breakers))

Here is a simple conversion script. Feel free to suggest improvements.

Related

How to generate a 10000 lines test file from original file with 10 lines?

I want to test an application with a file containing 10000 lines of records (plus header and footer lines). I have a test file with 10 lines now, so I want to duplicate these line 1000 times. I don't want to create a C# code in my app to generate that file (is only for test), so I am looking for a different and simple way to do that.
What kind of tool can I use to do that? CMD? Visual Studio/VS Code extension? Any thought?
If your data is textual, load the 10 records from your test file into an editor. Select all, copy, insert at the end of file. Repeat until the file is of length 10000+
This procedure requires ceil(log_2(1000)) cycles, 10 in your case, in general ceil(log_2(<target_number_of_lines>/<base_number_of_lines>)).
Alternative (large files)
Modern editors should not have performance problems here. However, the principle can be applied using a cat cli command. Assuming that you copy the original file into a file named dup0.txt proceed as follows:
cat dup0.txt dup0.txt >dup1.txt
cat dup1.txt dup1.txt >dup0.txt
leaving you with the quadrupled number of lines in dup0.txt.

How to number files on github so that they occur in sequence?

When I try to upload my folder to github the numbering goes like :
10 comes straight after 1 but I want normal numbering like 1 , 2, 3 and so on ... Can you tell me how to number the files so that it occurs normally ?
Try adding an underscore (or some character) at the beginning. That works in NTFS.

OpenMapTiles: Generate boundary admin_level 6 at lower zoom levels

I am wanting to show admin_level 6 boundaries at lower zoom levels (8, 7, 6), currently they start showing at zoom level 9.
I realize that I need to modify the import script so that this data is saved into the .mbtiles file. I have edited the boundary.sql file to change WHERE admin_level <= 4 to WHERE admin_level <= 6 for boundary_z6, boundary_z7 and boundary_z8.
I see the .sh file at /var/lib/docker/overlay/d9c758ee5fef79d79f0412880332a2efe66fd5c3d9614d6a710211c87e7bc04c/root/usr/src/app/import_osmborder_lines.sh, however I don't know if that will be overwritten at some point?
However, after a new import boundaries are still not shown at levels 8, 7, 6.
Looking deeper, it appears that I need to also modify the import_osmborder_lines.sh script so those lines get imported, but that is in its own docker file that I don't know how to edit so the quickstart.sh will use it.
How can I edit the import-osmborder docker file and have my quickstart.sh script use this for import? Or, am I going about this completely wrong?
I ended up editing the import_osmborder_lines.sh that is in the /var/lib/docker/ directory. This worked, but I still am not sure this is the ideal method.

How can I determine the version of a MAT file from MATLAB?

I am wondering if there is a way to determine whether a particular MAT file is v4, v6, v7 or v7.3?
I am looking for a solution that can determine the version using MATLAB code, preferably without having to load the data into memory.
There is some comment at the beginning of mat-files version 6 or following. This code reads it:
function txt=getMatComment(x)
fid=fopen(x);
txt=char(fread(fid,[1,140],'*char'));
txt=[txt,0];
txt=txt(1:find(txt==0,1,'first')-1);
end
It seems the comment is always 116 chars long, but I did not find any reference. This code reads 140 chars and cuts of at the end.
The part I don't understand: For Version 6 or 7 it says MATLAB 5.0 MAT-file

Why would PDF::FromHTML behave differently when called from my web app?

I'm using PDF::FromHTML to generate a PDF from HTML(as the name of the module would imply) :)
I'm able to run it from the command line fine and receive my expected output - however when I use the exact same code in my web app, the output doesn't look correct at all - text is appearing in the wrong places and not all of it is appearing.
I am using the exact same input file in the web app and on the command line - some reason when it's called from inside my web app, it's appearing differently.
Here is the code:
use PDF::FromHTML;
my $filename = '/tmp/backup.html';
my $font = 'Helvetica';
my $encoding = 'utf-8';
my $size = 12;
my $landscape = 0;
my $pdf = PDF::FromHTML->new(
encoding => $encoding,
);
my $input_file = $filename;
my $output_file = "$input_file.pdf";
warn "$input_file\n$output_file\n";
$pdf->load_file($input_file);
$pdf->convert(
Font => $font,
LineHeight => $size,
Landscape => $landscape,
);
$pdf->write_file($output_file);
The web app code is the same, just with that block thrown into a method.
I have looked at the two generated PDF files in a hex editor and found the differences. They're the same until a block whose intent I can't understand...
Good PDF contents at that block:
/Length 302 >> stream
**binary data
endstream endobj
10 0 obj << /Filter [ /FlateDecode ] /Length 966
Bad PDF contents:
/Length 306 >> stream
**binary data
endstream endobj
10 0 obj << /Filter [ /FlateDecode ] /Length 559
As you can see, the length of the content contained in here differs, as does the binary data contained in that stream(the length 302 vs length 306 one) as well as the next stream(the length 966 vs 559 one).
I'm not entirely sure what could be causing this discrepancy, the only thing I can think of is some sort of difference in the environments when I'm running this as my user on the command line versus running it from the web app. I don't know where I should start with debugging that, however.
In general, the CGI environment is different than your interactive login environment just like someone else's login environment is different than yours. The trick is to figure out what thing you have set or unset on your command line that makes your program work.
You might want to see my Troubleshooting Perl CGI scripts for a step-by-step method to track down these problems.
Some things to investigate:
Is your CGI script running on the same platform (i.e. is it a Windows versus Unix sorta thing)
What's different about the environment variables?
Does your CGI script use the same version of Perl?
Does that perl binary have different compilation options?
Are you using the same versions of the modules?
If some of those modules use external libraries, are they the same?
A useful technique is to make your login shell temporarily have the same setup as your CGI environment. Once you do that, you should get the same results on the command line even if those results are wrong. However, once you get the wrong results you can start tracking it down from the command line.
Good luck.
Couple of suggestions:
PDF::FromHTML uses PDF::Writer, which in turn uses a PDF rendering library as a plugin (think the options are PDFLib and some others). Are the same version of the libraries available as plugins?
Does your HTML input file have a CSS file that you haven't uploaded?
Try setting the other PDF::FromHTML variables: PageWidth, PageResolution, PageSize etc
Is the ordering of the output text different or merely the postions? If it's position then try setting the PageWidth etc as the library being used (PDFLib or whatever) may pick different defaults between the two environments. If ordering is wrong then I have no idea.
The two PDF blocks you posted don't really show much - just shows that the compressed sections are of different sizes. There's nothing actually wrong syntactically with either example.
Maybe there is some encoding problem? Have a look at the headers.
I would take a good look at what user the Web server is running as and what that users environment variables look like. Also pay attention to that users permissions on the directories. Also are there other things limiting the web server users such as SElinux on a linux box?