I'm using Geany 1.33 on Windows 10 and invoke it from command line for an empty (zero byte) file. Though in the Geany preferences on the Files page the "Default end of line characters" combobox is set to "Windows (CRLF)", pressing enter and saving in the empty file will write Unix (LF) line endings.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1950
I know this isn't a Geany issue directly, but maybe there's something that can be done to improve the build times. I ran some tests to measure the actual build times.
## Machines
* "Linux Native"
* Ubuntu 18.04
* 32GB RAM
* 6-core i7 @ 3.7GHz
* Entirely on SSD
* "Windows with MSYS2"
* Windows 10 Pro
* 32GB RAM
* 6-core i7 @ 3.7GHz
* Geany source code on SSD, system headers and build tools on mechanical HDD.
* "Linux VM Guest on Windows Host"
* ElementaryOS from 2018, in VirtualBox on Windows 10
* 4GB RAM
* 1-core emulated CPU (presumably 3.7GHz + VM overhead)
* All files in virtual disk stored on a mechanical HDD.
## Tests
* "configure" - `./configure [opts]`
* "make" - `make -j12` after a `make clean`
* "imake" - `touch src/build.h && make -j12` to do an incremental build
* "install" - `make -j12 install`
I used 12 `make` jobs on account of the 12 hyperthreads in the CPU, even in the VM which makes no sense since I only assigned it a single core. I used `time` on the above commands and took the average of 3 runs for each. All 3 runs were quite similar in all cases.
## The results
The Y axis is in seconds.
## Observations
* As expected `configure` was really slow on Windows since it spawns tons of processes.
* The Windows build seems to be spending a large portion of the time linking which is why even incremental build was still very slow.
* In the wimpy Linux VM with 1 core, the vast majority of the compile time was spent compiling Scintilla's C++ code, shown by how the incremental build that didn't touch C++ code is comparatively fast.
* I don't know whether it's the `ld` linker which is slow, the `libtool` stuff, or some combination.
## Possible Solutions?
The linking times even in the Libtool helper libraries is really slow, so maybe for Windows we could not use helper libraries and link all of the `libgeany` objects together in one go.
Maybe there's a way to get linking itself to be faster, needs investigation. Maybe a different build of `libtool` or something?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2305
Hi I am a competitive programmer and I like to reuse parts of the code but I find adding snippets in snippets.conf to be a bit tedious. Does a simple way exist?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2481
The Requirements section of the devhelp plugin page under http://plugins.geany.org lists the following items:
- GTK >= 2.16
- libwebkitgtk >= 1.1.18
- libdevhelp 1.0 >= 2.30.1 or libdevhelp 2.0 >= 2.32.0
Looking at the makefile I see this requirements:
```
[gtk+-2.0 >= ${GTK_VERSION}
webkit-1.0 >= ${WEBKIT_VERSION}
libwnck-1.0 >= ${LIBWNCK_VERSION}
gconf-2.0 >= ${GCONF_VERSION}
gthread-2.0
zlib])
```
On my Ubuntu machine only ```libwebkit``` and ```libwnck``` were missing. Not sure if the list on the plugin page should be extended.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/626
If one creates a Julia file and writes some code into it, one would expect all declared variables to be shown in the symbols list on the left. However, this is not the case, for instance in this code here:
```
a::Int8 = 3
function f(x)
return 2x
end
```
the variable `a` is not shown in the symbols list, but the function `f` is shown. Is this the normal behavior or is it a bug?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3341
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3341(a)github.com>
Every placeholder in the Statusbar Template may also specify width, e. g. `%3l`. Width is the minimum number of characters to be shown. If the value is shorter than width, the result is left-padded with spaces, or right-padded in case of negative width. The value is not truncated even if the result is larger.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3221
-- Commit Summary --
* Statusbar Template enhancement: width specifier.
* Style fix.
* Debug code dropped.
-- File Changes --
M doc/geany.txt (26)
M src/ui_utils.c (71)
-- Patch Links --
https://github.com/geany/geany/pull/3221.patchhttps://github.com/geany/geany/pull/3221.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3221
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3221(a)github.com>
Please welcome a new way to build Geany and Geany-Plugins for Windows in the CI.
What's in here:
- the workflow job to checkout Geany-Plugins, Geany and Infrastructure repositories
- use the supporting scripts in https://github.com/geany/infrastructure/tree/add_ci_builders/builders to
- build a Docker image with a full MSYS2 installation (or pull the image from the Geany Docker registry if available)
- use this Docker image to:
- build Geany and create a release-like installer for it as build dependency for the G-P build (or use cache if available)
- install Geany from the previously built Geany installer
- build Geany-Plugins and create and test an installer
- store the Geany and Geany-Plugins installer as artifact on Github
Mostly all of the work is done in the builder scripts on https://github.com/geany/infrastructure/tree/add_ci_builders/builders.
Unfortunately, it grew more than than expected in terms of amount of code.
I tried to document at least the basics so anyone else than me will be available to get an idea what is happening.
Let me know if it worked :).
There is a difference to the Linux CI build which more or less aims at using a rather old setup to ensure backwards compability.
The Mingw-w64 build instead always pulls the latest available packages from the MSYS2 repositories.
I think this is OK as this is also what we do on releases and since we bundle all dependencies into the installer (for release builds as well as for CI builds), the result should be consistent.
Best of all: during the CI build Windows installers are created for Geany and Geany-Plugins and they are stored as artifacts and can be downloaded later on (up to 30 days).
TODO:
- this branch needs a bit more testing with this PR
- we need to merge the PR XXX first
- for now, the necessary Docker image was uploaded to https://github.com/geany/infrastructure/pkgs/container/geany-mingw64-ci by me manually. Basically we could push the image also from the CI job but I'm hesitating to allow this because of the risks it offers to malicious users. Maybe I'll add a separate job in the infrastructure repository later to build and push the image there and restrict this job to admins
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1201
-- Commit Summary --
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
* Fix g-p source path
* CI: Add Windows build
* CI: Add Windows build
* CI: Add Windows build
-- File Changes --
M .github/workflows/build.yml (140)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1201.patchhttps://github.com/geany/geany-plugins/pull/1201.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1201
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1201(a)github.com>
This is a followup of #2630 to fully port the `scripts/create_py_tags.py` script for generating tags for the Python standard library to Python 3.
While continuing on @claudep's work, I noticed plain porting is harder than to more or less rewrite the script. Now the script works by fully importing the modules, if possible, to use Python's `inspect.Signature` API to extract symbols. If this is not possible, the existing regular expression based parser is used as fallback.
Deprecated modules are ignored completely as well as a couple of special modules like the included Idle IDE and executable modules in general.
I'm using the resulting tags file since a few weeks and it feels fine, much better than before especially because of the better extracted argument lists of functions and methods.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3039
-- Commit Summary --
* Refs #2615 - Convert create_py_tags.py to Python 3
* Rewrite Python standard library tags creation script for Python 3
-- File Changes --
M data/tags/std.py.tags (27660)
M scripts/create_py_tags.py (486)
-- Patch Links --
https://github.com/geany/geany/pull/3039.patchhttps://github.com/geany/geany/pull/3039.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3039