Thanks for the reply.
I'm on version g++-6 but there is a g++-7 in testing and unstable.
make reports that several variable forms are depracated just before announcing errors.
I have run some checks, without resolution, maybe a virtual machine would be a better vehicle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got Debian 8.3.0 from the wayback machine. Only disk 1 is needed as that has an installation image to boot into an install.
Note carefully the earlier comment about a 10GB virtual hard drive when setting up your virtualbox machine. It's a scary moment when the install asks to format your hard drive and will not take no for an answer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest saying no to a network install to get the basic machine built more quickly. Once the virtual machine is booted, and if you are familiar where the files should be, it should not be too difficult to complete the installation of the OS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, virtualbox, Debian, TkTable, ecolab, all up and in place.
This seems weird, but the couple of minsky downloads I've tried throw up this error :
gzip: stdin: not in gzip format
Really strange as the other files I downloaded opened ok.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Minsky compile stalls when it cannot find 'cairoSurfaceImage.h'
I'm tempted to just download that file and paste it into ecolab/include/
or should I get a newer version of ecolab?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Sat, Nov 17, 2018 at 03:54:45PM -0000, Richard A Lough wrote:
The Minsky compile stalls when it cannot find 'cairoSurfaceImage.h'
I'm tempted to just download that file and paste it into ecolab/include/
or should I get a newer version of ecolab?
You should always use the latest version. Minsky and EcoLab are
coevolving. If building from top of tree, then use the top of tree
version of EcoLab. If you're building the latest release, use the
latest EcoLab release. If you're building a historical version of
Minsky, then you can either use the latest EcoLab release (because it
is in theory backwards compatible, and in practice nearly so), or the
release of EcoLab nearest to the Minsky release.
CairoSurfaceImage is used extensively in Minsky 2.x.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK thanks. I downloaded Minsky.1.D45.tar.gz and got that to compile, so that seems to work. I've downloaded ecolab-5.55 and Minsky-2.8. The ecolab compile fails with the error message:
/usr/bin/ld: cannot find -lgdbm
collect2: error: ld returned 1 exit status
Makefile:236: recipe for target 'bin/ecolab' failed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I reverted to Minsky.1.D45, because I know that works, and built my model Sumer01g.mky.
I checked everything as the model got built, but now that the model is complete, I get a bunch of errors regarding font sizes, and failed font creations, and out of memory errors when I try to run, which seems odd.
I checked the output as a matlab file, and it is correct as far as I can tell.
Would giving more memory to the virtual machine fix this or is this an known problem with Minsky.1.D45?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Fri, Nov 23, 2018 at 04:43:48PM -0000, Richard A Lough wrote:
I reverted to Minsky.1.D45, because I know that works, and built my model
Sumer01g.mky.
I checked everything as the model got built, but now that the model is
complete, I get a bunch of errors regarding font sizes, and failed font
creations, and out of memory errors when I try to run, which seems odd.
I checked the output as a matlab file, and it is correct as far as I can tell.
Would giving more memory to the virtual machine fix this or is this an known
problem with Minsky.1.D45?
I remember those messages as pango being overly chatty, but ultimately
not important as far as I can tell. I haven't seen them for a while,
so maybe there was some weird pango configuration that got fixed at
some point. 1.D45 is over three years old, before we switched to using
github.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I can tell, all the ecolabs code works with Minsky.1.D45.
I'll have a look at the error messages for other Minsky versions, but for now, I'll see how the Sumer model runs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Mon, Nov 26, 2018 at 04:50:06PM -0000, Richard A Lough wrote:
As far as I can tell, all the ecolabs code works with Minsky.1.D45.
I'll have a look at the error messages for other Minsky versions, but for now,
I'll see how the Sumer model runs.
What version of EcoLab are you using? The latest is 5.55. Maybe you
are using the old version 5.D28?
Cheers
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
valid for at least: ecolab.5.D48; ecolab-5.42; ecolab-5.44; and ecolab-5.55. I'm running on ecolab-5.55 with Minsky.1.D45 now, presently on Debian Jessie. (ver 8.3.0 with oldstable updates)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes - the bgu led to almost empty .deb files being created.
The .deb file is now 4.2 MB.
Cheers
On Sun, Feb 02, 2020 at 04:39:18AM -0000, Kresimir wrote:
It seems that instalation .deb file for Ubuntu 18.04 is very small in size. It
has only 1,2 kB. Previous installation file was larger in size. I have same
system in virtualbox and also could not run beta there.
I desided to retrace some steps as something odd may have happened.
the config.log for TkTable ends with a couple of exit 0's so that seems good.
The /use/local/lib seemed to be missing its file. I did a make clean, make
I now have libTkTable2.11.so in the current directory (but no TkTable2.11.so there)
hence that's the file that gets copied to /usr/local/lib
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Tue, Nov 13, 2018 at 10:06:16PM -0000, Richard A Lough wrote:
I desided to retrace some steps as something odd may have happened.
the config.log for TkTable ends with a couple of exit 0's so that seems good.
The /use/local/lib seemed to be missing its file. I did a make clean, make
I now have libTkTable2.11.so in the current directory (but no TkTable2.11.so
there)
hence that's the file that gets copied to /usr/local/lib
Why are you installing TkTable? TkTable is no longer used in Minsky 2.x.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As feedback information from me is that I switched from Windows 7 to Ubuntu on new computer and it seems to me, so far now, that software runs better and faster on Linux. I have to run Minsky from terminal each time but that is not important to me. I have probably made some mistake when installing software.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Thu, Nov 22, 2018 at 02:01:48PM -0000, Kresimir wrote:
As feedback information from me is that I switched from Windows 7 to Ubuntu on
new computer and it seems to me, so far now, that software runs better and
faster on Linux. I have to run Minsky from terminal each time but that is not
important to me. I have probably made some mistake when installing software.
I haven't looked into desktop integration. I assume users are familiar
enough with their chosen window manager to create their own desktop
link, and file associations.
I always run Minsky from the command line on Linux... :).
Cheers
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried again to build with the latest code.
The first thing that got flagged up was that the shell pointed to 'dash' instead of 'bash' , so that got fixed.
Next was that Minsky could not find cairoSurfaceImage.h - and it wasn't in the
/usr/ecolab/include directory - I deleted the /usr and /ecolab* directories and reinstalled ecolab-5.55. That seems to have got me past that problem.
Minsky-2.8 still fails but with this error: minsky.o: In function classdesc::enable_if<std::is_enum<json_spirit::Value_type>, std::ostream&>::T classdesc::operator<< <json_spirit::Value_type>(std::ostream&, json_spirit::Value_type)':
minsky.cc:(.text._ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5_[_ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5_]+0xb): undefined reference toclassdesc::(anonymous namespace)::enum_keysData<json_spirit::value_type>::keys'
minsky.cc:(.text.ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5[ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5]+0x17): undefined reference to `classdesc::(anonymous namespace)::enum_keysData<json_spirit::value_type>::keys'
collect2: error: ld returned 1 exit status
Makefile:169: recipe for target 'gui-tk/minsky' failed</json_spirit::value_type></json_spirit::value_type>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried today to install version 2.13 on Opensuse Thumbleweed KDE, which I have in virtualbox, but got some message about dependencies. It is in attachment - something about Yast 2 and Ruby 2.5.
It is off less importance to me, because I already have two other functional versions on Ubuntu and Windows 10 (virtualbox).
It seems to me so far now, that OpenSuse is easier to run from virtualbox than Windows 10 which is difficult to scroll.
Did you change recently how minsky beta is runned from terminal? I couldn't run latest beta from it, although it seems that software is installed. When I type "minsky", terminal throws message "command not found".
There hasn't been any such changes. Maybe trying reinstalling it?
On Sat, Feb 01, 2020 at 07:52:23AM -0000, Kresimir wrote:
Did you change recently how minsky beta is runned from terminal? I couldn't run
latest beta from it, although it seems that software is installed. When I type
"minsky", terminal throws message "command not found".
Thanks for the reply.
I'm on version g++-6 but there is a g++-7 in testing and unstable.
make reports that several variable forms are depracated just before announcing errors.
I have run some checks, without resolution, maybe a virtual machine would be a better vehicle.
Got Debian 8.3.0 from the wayback machine. Only disk 1 is needed as that has an installation image to boot into an install.
Note carefully the earlier comment about a 10GB virtual hard drive when setting up your virtualbox machine. It's a scary moment when the install asks to format your hard drive and will not take no for an answer.
A useful website, recommends 32GB of virtual hard disk for a Debian installation.
http://www.brianlinkletter.com/installing-debian-linux-in-a-virtualbox-virtual-machine/
I suggest saying no to a network install to get the basic machine built more quickly. Once the virtual machine is booted, and if you are familiar where the files should be, it should not be too difficult to complete the installation of the OS.
Ok, virtualbox, Debian, TkTable, ecolab, all up and in place.
This seems weird, but the couple of minsky downloads I've tried throw up this error :
gzip: stdin: not in gzip format
Really strange as the other files I downloaded opened ok.
The sourceforge downloader is too smart for its own good, and the old link no longer works.
this link works today :
wget https://sourceforge.net/projects/minsky/files/Sources/Minsky-2.8.tar.gz/download
Just rename the file form 'download' to Minsky-2.8.tar.gz
The Minsky compile stalls when it cannot find 'cairoSurfaceImage.h'
I'm tempted to just download that file and paste it into ecolab/include/
or should I get a newer version of ecolab?
On Sat, Nov 17, 2018 at 03:54:45PM -0000, Richard A Lough wrote:
You should always use the latest version. Minsky and EcoLab are
coevolving. If building from top of tree, then use the top of tree
version of EcoLab. If you're building the latest release, use the
latest EcoLab release. If you're building a historical version of
Minsky, then you can either use the latest EcoLab release (because it
is in theory backwards compatible, and in practice nearly so), or the
release of EcoLab nearest to the Minsky release.
CairoSurfaceImage is used extensively in Minsky 2.x.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
OK thanks. I downloaded Minsky.1.D45.tar.gz and got that to compile, so that seems to work. I've downloaded ecolab-5.55 and Minsky-2.8. The ecolab compile fails with the error message:
/usr/bin/ld: cannot find -lgdbm
collect2: error: ld returned 1 exit status
Makefile:236: recipe for target 'bin/ecolab' failed
needs libgdbm-dev - that solves the ecolab issue. Minsku fails with message :
/bin/sh: 1: Syntax error: Bad fd number
Makefile:102: Boost extension=
g++ -c -fPIC -I. -I/home/k-minsky/usr/ecolab/include -DHASH_TCL_hash -DHAVE_LONGLONG -DTR1 -I/home/k-minsky/usr/ecolab/include -I/home/k-minsky/usr/include -I/usr/local/include -I/opt/local/include -I/usr/X11R6/include -DGNUSL -DZLIB -DXDR_PACK -DCAIRO -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -DCONTIGUOUS -DTK -I/usr/include/tcl8.6 -I/usr/include/tcl8.6 -DECOLAB_LIB=\"/home/k-minsky/usr/ecolab/include\" -DNDEBUG -I/home/k-minsky/usr/ecolab/include -DPANGO -pthread -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -std=c++11 -Ischema -Iengine -Imodel -O3 -UECOLAB_LIB -DECOLAB_LIB=\"library\" -Wno-unused-local-typedefs -pthread -I/usr/include/librsvg-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -DBOOST_SIGNALS_NO_DEPRECATION_WARNING -O3 -o tclmain.o tclmain.cc
tclmain.cc: In function ‘int main(int, char)’:
tclmain.cc:86:3: error: ‘defaultFamily’ is not a member of ‘ecolab::Pango’
ecolab::Pango::defaultFamily="Adobe Courier Regular";
^
/home/k-minsky/usr/ecolab/include/Makefile:563: recipe for target 'tclmain.o' failed
make: * [tclmain.o] Error 1
I reverted to Minsky.1.D45, because I know that works, and built my model Sumer01g.mky.
I checked everything as the model got built, but now that the model is complete, I get a bunch of errors regarding font sizes, and failed font creations, and out of memory errors when I try to run, which seems odd.
I checked the output as a matlab file, and it is correct as far as I can tell.
Would giving more memory to the virtual machine fix this or is this an known problem with Minsky.1.D45?
On Fri, Nov 23, 2018 at 04:43:48PM -0000, Richard A Lough wrote:
I remember those messages as pango being overly chatty, but ultimately
not important as far as I can tell. I haven't seen them for a while,
so maybe there was some weird pango configuration that got fixed at
some point. 1.D45 is over three years old, before we switched to using
github.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
As far as I can tell, all the ecolabs code works with Minsky.1.D45.
I'll have a look at the error messages for other Minsky versions, but for now, I'll see how the Sumer model runs.
On Mon, Nov 26, 2018 at 04:50:06PM -0000, Richard A Lough wrote:
What version of EcoLab are you using? The latest is 5.55. Maybe you
are using the old version 5.D28?
Cheers
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
valid for at least: ecolab.5.D48; ecolab-5.42; ecolab-5.44; and ecolab-5.55. I'm running on ecolab-5.55 with Minsky.1.D45 now, presently on Debian Jessie. (ver 8.3.0 with oldstable updates)
.
Last edit: Kresimir 2020-02-02
Yes - the bgu led to almost empty .deb files being created.
The .deb file is now 4.2 MB.
Cheers
On Sun, Feb 02, 2020 at 04:39:18AM -0000, Kresimir wrote:
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders hpcoder@hpcoders.com.au
http://www.hpcoders.com.au
I desided to retrace some steps as something odd may have happened.
the config.log for TkTable ends with a couple of exit 0's so that seems good.
The /use/local/lib seemed to be missing its file. I did a make clean, make
I now have libTkTable2.11.so in the current directory (but no TkTable2.11.so there)
hence that's the file that gets copied to /usr/local/lib
On Tue, Nov 13, 2018 at 10:06:16PM -0000, Richard A Lough wrote:
Why are you installing TkTable? TkTable is no longer used in Minsky 2.x.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
TkTable 2.11 is listed under dependencies in the wiki - Building Minsky
See also on this thread at 2016-02-01
As feedback information from me is that I switched from Windows 7 to Ubuntu on new computer and it seems to me, so far now, that software runs better and faster on Linux. I have to run Minsky from terminal each time but that is not important to me. I have probably made some mistake when installing software.
On Thu, Nov 22, 2018 at 02:01:48PM -0000, Kresimir wrote:
I haven't looked into desktop integration. I assume users are familiar
enough with their chosen window manager to create their own desktop
link, and file associations.
I always run Minsky from the command line on Linux... :).
Cheers
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
I tried again to build with the latest code.
The first thing that got flagged up was that the shell pointed to 'dash' instead of 'bash' , so that got fixed.
Next was that Minsky could not find cairoSurfaceImage.h - and it wasn't in the
/usr/ecolab/include directory - I deleted the /usr and /ecolab* directories and reinstalled ecolab-5.55. That seems to have got me past that problem.
Minsky-2.8 still fails but with this error: minsky.o: In function
classdesc::enable_if<std::is_enum<json_spirit::Value_type>, std::ostream&>::T classdesc::operator<< <json_spirit::Value_type>(std::ostream&, json_spirit::Value_type)': minsky.cc:(.text._ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5_[_ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5_]+0xb): undefined reference toclassdesc::(anonymous namespace)::enum_keysData<json_spirit::value_type>::keys'minsky.cc:(.text.ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5[ZN9classdesclsIN11json_spirit10Value_typeEEENS_9enable_ifISt7is_enumIT_ERSoE1TES7_S5]+0x17): undefined reference to `classdesc::(anonymous namespace)::enum_keysData<json_spirit::value_type>::keys'
collect2: error: ld returned 1 exit status
Makefile:169: recipe for target 'gui-tk/minsky' failed</json_spirit::value_type></json_spirit::value_type>
I tried today to install version 2.13 on Opensuse Thumbleweed KDE, which I have in virtualbox, but got some message about dependencies. It is in attachment - something about Yast 2 and Ruby 2.5.
It is off less importance to me, because I already have two other functional versions on Ubuntu and Windows 10 (virtualbox).
It seems to me so far now, that OpenSuse is easier to run from virtualbox than Windows 10 which is difficult to scroll.
Last edit: Kresimir 2019-03-15
Did you change recently how minsky beta is runned from terminal? I couldn't run latest beta from it, although it seems that software is installed. When I type "minsky", terminal throws message "command not found".
There hasn't been any such changes. Maybe trying reinstalling it?
On Sat, Feb 01, 2020 at 07:52:23AM -0000, Kresimir wrote:
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders hpcoder@hpcoders.com.au
http://www.hpcoders.com.au