profile
viewpoint
Simon Sobisch GitMensch Germany At day being either at work or with my kids and hacking software (especially [GnuCOBOL](https://www.gnu.org/software/gnucobol/)) at night.

lexxmark/winflexbison 172

Main winflexbision repository

Bill-Gray/PDCursesMod 154

Public Domain Curses - a curses library for environments that don't fit the termcap/terminfo model, modified and extended from the 'official' version

GitMensch/code-debug 0

Native debugging for VSCode

GitMensch/devdocs 0

API Documentation Browser

GitMensch/flex 0

The Fast Lexical Analyzer - scanner generator for lexing in C and C++

GitMensch/gnucobol-debug 0

GnuCOBOL debugger

GitMensch/GnuCOBOL-Win32-MinGW 0

GnuCOBOL binaries for windows

GitMensch/homebrew-core 0

🍻 Default formulae for the missing package manager for macOS

issue commentOlegKunitsyn/gnucobol-debug

test with GnuCOBOL 1.1 / open source COBOL

The only way to do what -A/-Q is doing is to query cobc --info for COB_LDFLAGS (often empty) and COB_CFLAGS and add the own parameters to this:

C:\TEMP>cobc D:\dev\GC11\extras\CBL_OC_DUMP.cob -v
preprocessing D:\dev\GC11\extras\CBL_OC_DUMP.cob into C:\TEMP\cob9434.cob
parsing C:\TEMP\cob9434.cob (D:\dev\GC11\extras\CBL_OC_DUMP.cob)
Return status:  0
translating C:\TEMP\cob9434.cob into C:\TEMP\cob9435.c (D:\dev\GC11\extras\CBL_OC_DUMP.cob)
gcc -pipe -I"D:\dev\GC11\include"  -Wno-unused -fsigned-char -Wno-pointer-sign  -shared -L"D:\dev\GC11\lib"  -DDLL_EXPORT -DPIC -Wl,--export-all-symbols -Wl,--enable-auto-import -o D:\dev\GC11\extras\CBL_OC_DUMP.dll C:\TEMP\cob9435.c -L/mingw/lib -lcob -lm -lgmp -lpdcurses -ldb-6.1

C:\TEMP>set "COB_LDFLAGS=-L"D:\dev\GC11\lib" --coverage"

C:\TEMP>cobc D:\dev\GC11\extras\CBL_OC_DUMP.cob -v
preprocessing D:\dev\GC11\extras\CBL_OC_DUMP.cob into C:\TEMP\cob4143.cob
parsing C:\TEMP\cob4143.cob (D:\dev\GC11\extras\CBL_OC_DUMP.cob)
Return status:  0
translating C:\TEMP\cob4143.cob into C:\TEMP\cob4144.c (D:\dev\GC11\extras\CBL_OC_DUMP.cob)
gcc -pipe -I"D:\dev\GC11\include"  -Wno-unused -fsigned-char -Wno-pointer-sign  -shared -L"D:\dev\GC11\lib" --coverage -DDLL_EXPORT -DPIC -Wl,--export-all-symbols -Wl,--enable-auto-import -o D:\dev\GC11\extras\CBL_OC_DUMP.dll C:\TEMP\cob4144.c -L/mingw/lib -lcob -lm -lgmp -lpdcurses -ldb-6.1
GitMensch

comment created time in an hour

pull request commentshashi278/cobol-lang-syntax

Update LICENSE

Note: nice side effect is that the license is now correctly recognized as MIT: https://github.com/shashi278/cobol-lang-syntax/blob/master/LICENSE

GitMensch

comment created time in 4 hours

delete branch GitMensch/cobol-lang-syntax

delete branch : patch-1

delete time in 4 hours

issue commentOlegKunitsyn/gnucobol-debug

debug without (re-)compile

@brunopacheco1 Just a friendly ping: any update yet and/or the option to work on this soon?

GitMensch

comment created time in 16 hours

issue commentOlegKunitsyn/gnucobol-debug

test with GnuCOBOL 1.1 / open source COBOL

As there is a docker container for GnuCOBOL 1.1 now - is there any test result for this already? Any "known issues" (things that possibly need adjustments and/or stuff that can be documented as "regresseion when using with GnuCOBOL 1.1, consider updating)?

GitMensch

comment created time in 16 hours

issue commentusernamehw/vscode-error-lens

FR: setting to show the inline text after a specified column

As it is "help wanted" - where is the position of the text currently defined?

GitMensch

comment created time in 16 hours

pull request commentshashi278/cobol-lang-syntax

Update LICENSE

Note "open" would be the possibly harder to adjust https://marketplace.visualstudio.com/items/shashi278.cobol-lang-syntax/license (just adding the copyright line should be enough there).

GitMensch

comment created time in 16 hours

issue openedshashi278/cobol-lang-syntax

Question: Why should one prefer this extension over bitlang.cobol?

As the syntax seems to have been copied (which is perfectly fine with MIT-licensed code) it would be good to answer this question in the README.

I guess it maybe is about https://github.com/shashi278/cobol-lang-syntax/blob/master/language-configuration.json ? If yes, can you create a PR against bitlang.cobol to add this function?

created time in 16 hours

PR opened shashi278/cobol-lang-syntax

Update LICENSE

removed double-license using a common place for the copyright owners

+1 -21

0 comment

1 changed file

pr created time in 16 hours

push eventGitMensch/cobol-lang-syntax

Simon Sobisch

commit sha 67faa7f5fb0f8086160bec6fe72124bda7a2e281

Update LICENSE removed double-license using a common place for the copyright owners

view details

push time in 16 hours

issue commentspgennard/vscode_cobol

Extension causes high cpu load

I think the cache/storagepath is a broken implementation and I am now pondering what to do with it. Removing/deprecating it is one option.. enforcing the user to provide a "workspace" id to act as a sub-folder within the storagepath is another...

@spgennard please don't remove the cache/storagepath option as the cache/workspace option is also "broken".

cache/workspace is broken for multiuser access to the same workspace (concerning write/permission/locking), the current work-around is to switch to cache/storagepath. One could also (optionally?) use-sub-folders here with the username but I'd document to just use the cache/storagepath setting in this use-case [and not change anything for cache/workspace].

cache/storagepath as-is is broken because for multiple workspaces the same user should have multiple caches (some users only have a single workspace so they aren't affected by this current problem). So yes: a subfolder would be the most reasonable approach. I suggest to allow the user to specify a workspace id, if it isn't set fall-back to the workspace name (so a user that has a COBOL.workspace in three different folders would need to specify a workspace-id at least two times - or, if he's a single user switch to cache/workspace instead, but a user who has PROJECT1.workspace, PROJECT2.workspace PROJECT3.workspace wouldn't have to setup anything).

GitMensch

comment created time in 17 hours

pull request commentspgennard/vscode_cobol

Update for GnuCOBOL matchers

@spgennard As the gnucobol-cobc now matches also GC3 format and the gnucobol-cobc-warning and gnucobol-cobc-error now also match the old GC format I highly suggest to drop the gnucobol3-cobc pattern matcher. I think (but have not verified that) that the gnucobol matchers would also match the opencobol versions allowing further tidy up. I suggest to officially deprecate the opencobol ones, documenting that the gnucobol ones (which are de-facto from the same "product") should be used and remove the opencobol ones in some months.

GitMensch

comment created time in 17 hours

PR opened spgennard/vscode_cobol

Update for GnuCOBOL matchers
  • added code attribute to all gc-matchers
  • made all gc-matchers apply to old and new versions by using an optional space
  • added Dutch, French and Serbian for GC
  • replaced \\s by plain space and removed optional ignored values where they never occurred (OC, C*IT, GC)
  • added samples for OC 1.1, GC2, GC3.1 format in the tests (match as expected in the testsuite)

Follow-up to 5b15c769d0bc3c7bd17646362c49a0b578150c01.

+33 -21

0 comment

2 changed files

pr created time in 17 hours

delete branch GitMensch/vscode_cobol

delete branch : patch-1

delete time in 17 hours

PR closed spgennard/vscode_cobol

Update bld_cobscanner.sh

The testing and creation seems to be obsolete as there's a cobscanner directory with content in this repo and I'm not sure if the later npm command would work if the contained package-lock.json would not be in the repo.

+1 -3

1 comment

1 changed file

GitMensch

pr closed time in 17 hours

pull request commentspgennard/vscode_cobol

Update bld_cobscanner.sh

Obsoleted by b94aeec.

GitMensch

comment created time in 17 hours

push eventGitMensch/vscode_cobol

Simon Sobisch

commit sha bb01d0cc32e56aa52f57f52d71fd93d1a6f5e910

Update for GnuCOBOL matchers * added code attribute to all gc-matchers * made all gc-matchers apply to old and new versions by using an optional space * added Dutch, French and Serbian for GC * replaced `\\s` by plain space and removed optional ignored values where they never occurred (OC, C*IT, GC) * added samples for OC 1.1, GC2, GC3.1 format in the tests (match as expected in the testsuite)

view details

push time in 17 hours

issue commentspgennard/vscode_cobol

can't run the tests

Running the tests from the integrated terminal resultied in downloading of the vscode-1.50.1-zip and afterwards a

warning: 'sandbox' is not in the list of known options, but still passed to Electron/Chromium.

A second run works directly out of the box. Also working: running the tests via Terminal->Run Tasks->npm->run tests. (the debug configuration still does not work). I guess there may be a developer docs that says how to run the tests and listing those two options there somedayTM.

GitMensch

comment created time in 19 hours

issue commentspgennard/vscode_cobol

Building extension on win32 does not work anymore (cobscanner)

npm ERR! code ELIFECYCLE npm ERR! syscall spawn C:\Program Files\git\bin\bash.exe npm ERR! file C:\Program Files\git\bin\bash.exe npm ERR! path C:\Program Files\git\bin\bash.exe npm ERR! errno ENOENT

;-)

Using an existing shell helped here (but likely some other node stuff will someday be broken and I'll possibly have forgotten that I've tweaked the shell that way)... So win: the extension does start now with "Launch Extension", leaving #233, but I'll try the approach mentioned there.

GitMensch

comment created time in 19 hours

issue commentspgennard/vscode_cobol

Building extension on win32 does not work anymore (cobscanner)

config issue, see above

maybe "developer documentation issue"?

GitMensch

comment created time in 21 hours

issue commentspgennard/vscode_cobol

cobscanner npm install with warnings

Hm, looks like it would be easy to fix, can I PR the cobscanner/package.json to fix that?

GitMensch

comment created time in a day

issue openedspgennard/vscode_cobol

can't run the tests

This is possibly a win32 issue:

Error: Error: Cannot find module 'c:\dev\vscode_cobol.git\out\test'
Require stack:
- c:\Program Files\VSCodium\resources\app\out\vs\loader.js
- c:\Program Files\VSCodium\resources\app\out\bootstrap-amd.js
- c:\Program Files\VSCodium\resources\app\out\bootstrap-fork.js
	at p._doHandleExtensionTests (c:\Program Files\VSCodium\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:930:522)
	at processTicksAndRejections (internal/process/task_queues.js:94:5)

"c:\dev\vscode_cobol.git\out\test" is an existing folder in the file system with a content of runtTest.js[.map] and a suite folder which looks also fine.

created time in a day

issue openedspgennard/vscode_cobol

cobscanner npm install with warnings

Seen when running the tests:

cobscanner> npm install
npm WARN cobscanner@6.9.16 No description
npm WARN cobscanner@6.9.16 No repository field.

created time in a day

push eventGitMensch/vscode_cobol

Simon Sobisch

commit sha 509520d473debc08ad1d6211cd7877589fc67d8c

Update bld_cobscanner.sh

view details

push time in a day

PR opened spgennard/vscode_cobol

Update bld_cobscanner.sh

The testing and creation seems to be obsolete as there's a cobscanner directory with content in this repo and I'm not sure if the later npm command would work if it isn't.

+0 -2

0 comment

1 changed file

pr created time in a day

push eventGitMensch/vscode_cobol

Simon Sobisch

commit sha bacd6ad0596e36aa5526dd11f7babad208a57144

Update bld_cobscanner.sh

view details

push time in a day

issue openedspgennard/vscode_cobol

Buildin extensio on win32 does not work any more (cobscanner)

the command tsc -b && ./bld_cobscanner.sh does not work because there's no shell interpreter available (ps/cm should work) and because ./ won't work from the cmd which is the default interpreter

created time in a day

fork GitMensch/vscode_cobol

Visual Studio Code Extension for COBOL, JCL and MF Directive Files

fork in a day

issue openedspgennard/vscode_cobol

add acucobol-listing

While this has no priority for me (feel free to leave it open until I come back someday to create a PR) it looks like a current missing bit (ACU dialect, but no ACU listing). Other than the first column ("listing address", used for runtime error positions and for the debugger) it has nearly no special stuff (only the first lines on the first page that contain the compile commands and - if set relatad environment variables like CPYDIR [not in this sample]) SM103A.lst SM103A-wide.lst

created time in a day

pull request commentspgennard/vscode_cobol

recognize GnuCOBOL listings

Seems like handled with https://github.com/spgennard/vscode_cobol/commit/3922141761813947de191e7334cd1bff83caf51d

GitMensch

comment created time in a day

pull request commenteclipse/openvsx

Implemented the extension detail changes tab

Marvellous! So is there a follow up issue for the initializer changes (as noted) and for the one-time initialization for the changes?

IronGeek

comment created time in 2 days

pull request commentspgennard/vscode_cobol

recognize GnuCOBOL listings

Just a short ping on this - is this PR fine or does it need adjusting?

GitMensch

comment created time in 3 days

pull request commentspgennard/vscode_cobol

Added support for the COBOL keyword CHAINING

As it is integrated now it looks like this PR can be closed.

MCEmperor

comment created time in 3 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

Thanks for the note, yes, this did work. It may be reasonable to delete this in the extension when "clean metadata" is used. One thing I've recognized: there's no output during the scan, so there seems to be "nothing done" after the "Files found: xyz" entry (currently needs 60-85 seconds for the complete workspace).

If the notification API allows showing and removing notifications it may be good to show one "... in progress" and maybe update it each N seconds with a counter "processing 123/456 files for metadata...".

GitMensch

comment created time in 3 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

Just an update - rechecked 6.9.15 on both GNU/Linux and Windows I always get "Source scanner already active, no action taken" (this may be related to the process on start setting, but there's no output of it - instead it starts with "scanner already active").

Note: I do like the notification which shows up "Unable to clear metadata while caching is already in progress".

GitMensch

comment created time in 3 days

pull request commentspgennard/vscode_cobol

Added support for the COBOL keyword CHAINING

Looks good to me.

MCEmperor

comment created time in 3 days

pull request commentlexxmark/winflexbison

Fixed some redefinition questions caused by the skel.c file and some …

The change of the binary names is something I've thought about before, but it is a quite intrusive change, likely breaking people's build scripts. too (actually the one I use check for win_bison in PATH and fallback to bison if not found, but I guess this won't be true for many others). If we apply this then the build rules https://github.com/lexxmark/winflexbison/tree/master/custom_build_rules needs to be adjusted for the new name, too. It would remove additional symlinks that are currently needed when using the binaries with configure or similar scripts that only look for "bison" and "flex" and for possibly re-integrating the testsuites, so I'm not "against this" in general.

In any case I'd suggest to not mix that with the redefinitions but keep that as separate PR.

As this repo says the code depends on "Visual Studio 2015 or newer" and all those are covered with the CI which passes I'd merge the PR for this part directly, can I suggest you to force-push that?

libo3019

comment created time in 4 days

issue commentjson-c/json-c

FR: documenting the ABI (since ....)

I'm updating the topic start to add the since-documentation link.

GitMensch

comment created time in 5 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

Thank you for the information. I'll go on with the check. Just updated to that version, did the suggested restart to enable it and (as I still found no option to always show the output pane, if you know how to do please share) used "process files in workspace for metadata". Result seen after opening the output pane:

Starting to process metadata from workspace folders (startup)
 - Parsing x:\project1\src\GENERAL.pco                      (32590.00ms)

Starting to process metadata from workspace folders (on demand)
Scan completed (Exit Code=1)
Scan completed (Exit Code=1)

(the file mentioned is the one that was opened)

Then run the metadata processing again and as it did not worked tried with clean and starting again:

Starting to process metadata from workspace folders (on demand)
Scan completed (Exit Code=1)
Metadata cache cleared

Starting to process metadata from workspace folders (on demand)
Scan completed (Exit Code=1)

So it looks like it always exits with 1 and does no scan. Clean again, opened a file not under control of this extension, restarted:

VSCode version : 1.50.0
 Platform          : win32
 Architecture      : x64
Extension Information:
 Extension path    : c:\Users\SUSER\.vscode-oss\extensions\bitlang.cobol-6.9.11
 Version           : 6.9.11
 Caching
  Cache Strategy               : storagepath
  Cache directory              : c:\Users\SUSER\AppData\Roaming\VSCodium\User\workspaceStorage\f00b06fce209b941ff2b9a6714a46820\bitlang.cobol
 UNC paths disabled            : false
 Parse copybook for references : true
  Workspace Folders:
  [...]
  Combined Workspace and CopyBook Folders to search:
  [...]
  Invalid CopyBook directories (35)
  [...]

Starting to process metadata from workspace folders (startup)
Scan completed (Exit Code=1)

So - broken?

GitMensch

comment created time in 5 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

I see. That sounds reasonable. Do you see a reason to not upload 6.9.11 to open-vsx yet?

GitMensch

comment created time in 6 days

issue commentspgennard/vscode_cobol

external cobscanner increasing the download size nearly 15 times

Just for reference, https://github.com/spgennard/vscode_cobol/releases/tag/6.9.11 moved it back to the old size using node fork instead of spawning a native executable, for details see https://github.com/spgennard/vscode_cobol/issues/215#issuecomment-716068167.

GitMensch

comment created time in 6 days

issue commentOlegKunitsyn/gnucobol-debug

test with GnuCOBOL 1.1 / open source COBOL

Unknown option -job.

That's expected as this option

-j [<args>], -job[=<args>] run program after build, passing <args>

is available since GnuCOBOL 2.2rc, not in an earlier version (including OpenCOBOL 2 dev/beta)

How to pass arguments to OC 1.1. properly?

--job just runs the binary after creation (either via cobcrun if it was compiled as a module or as executable itself), it is mostly used for quick tests and for COBOL "scripting" (using cobc -j in the interpreter line, then executing it).

It should not be considered a general purpose function and is not available in OpenCOBOL, open-source cobol, GnuCOBOL 1.1 or C*IT, so for gnucobol-debug I'd recommend against using it. Instead: check the return status of cobc for zero and depending on the execute either cobcrun prog args or prog args. That also reminds me on my personal biggest issue with this extension: #63.

GitMensch

comment created time in 7 days

issue openedjson-c/json-c

FR: documenting the ABI (since ....)

As a followup-up to the discussion in https://github.com/json-c/json-c/commit/c2c94024f5d15c2fe36c72cb139df6a2ccd9b3ec:

Probably a better way to track the history of symbols is in documentation, like the "Since: 2.32" seen in the doc-comments in GNOME libraries.

I don't know how the GNOME libraries actually do this (@smcv may share some experiences here) so I suggest to have this documented in the source, as the headers of json-c document very well, for example https://github.com/json-c/json-c/blob/master/json_object.h#L125 I suggest to add an entry like @since 0.12 to these headers.

created time in 7 days

PR closed Bill-Gray/PDCursesMod

Reviewers
wincon/wingui: use async PlaySound for PDC_beep fixing #190

partially reverting 78e6949bbd304e3a41bcb687c398a0820b9100a9

I consider an interrupted sound in case of "rapid-fire" better than a "hanging screen i/o"

+3 -3

1 comment

3 changed files

GitMensch

pr closed time in 7 days

pull request commentBill-Gray/PDCursesMod

wincon/wingui: use async PlaySound for PDC_beep fixing #190

Happily closed, following the originating issue #190

GitMensch

comment created time in 7 days

CommitCommentEvent

PR opened lexxmark/winflexbison

Development->master

Open question: Should we wrap the binary mode in an environment variable or can it go in as-is?

And after pulling the branch we may should delete it, preventing PR against it...

+14 -1

0 comment

3 changed files

pr created time in 8 days

issue commentlexxmark/winflexbison

Can not fix file via --update

When you already define the function I'd suggest to add that part of the gnulib definition "just in case":

#if defined _WIN32 && ! defined __CYGWIN__
  if (strcmp (filename, "/dev/null") == 0)
    filename = "NUL";
#endif
voodoo66

comment created time in 8 days

issue commentlexxmark/winflexbison

Can not fix file via --update

Rechecked: the current gnulib fopen imnplementation does nothing like the article, it may still be most reasonable to adjust this module, use it and send it upstream to gnulib. Then let upstream bison use the updated module (preventing the need for patching again and again).

What do you think?

Side note: I'm just remembering that we have #17, using those would likely have caught this issue up-front...

voodoo66

comment created time in 8 days

issue commentlexxmark/winflexbison

Can not fix file via --update

Thank you for sharing the article. I've had a hope that the gnulib fopen module (not checked if bison uses it already) would fix this, but as https://www.gnu.org/software/gnulib/manual/html_node/fopen.html doesn't mention that part i guess not.

So what should be done next?

  • investigate if the gnulib module is used, and if not if it would solve the issue (using the fopen module may be easily done upstream)
  • work around the issue by manually wrapping fopen as mentioned in the article - in this case likely not replacing the calls in the code but add an extra definition and a #define fopen fopen_unixlike
voodoo66

comment created time in 8 days

issue commentlexxmark/winflexbison

Can not fix file via --update

Hm, can you rename the containing folder? if not then my mind has played me a trick and this is only possible for files opened for read (which does work, doesn't it?)

voodoo66

comment created time in 8 days

issue commentlexxmark/winflexbison

Can not fix file via --update

I'm sure that this is true when you rename a file via Windows Explorer which may means that either different ways of doing the rename are needed or that only a different process can rename the file.

voodoo66

comment created time in 8 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

Embedding the js in the exe and not compiling on Windows...

I'm confused now: is the .js in the exe (=compiled) or not? Note: there's still an included extension\bin\cobscanner-x64-win-6.9.6.exe, but I guess this may be correct? Would something similar be reasonable for MacOS?

Rechecked on Windows with 6.9.10: Processing files in Workspace works in general, the executable mentioned above (which describe itself as "Node.js: Server-side JavaScript") is spawned and processes all files. Question: Would it be possible to start it as multiple process [the linux environment finishes in 30seconds with 100% cpu load [one of the processors], the Windows environment does more or less idle]?

Side notes: after using "clear metadata" I was able to start "process workspace for metadata" multiple times, leading to multiple cobscanner instances running at the same time (processing the same files multiple times, ending with "Scan completed (Exit-Status 1)" in the output; a single scan ends just with "Scan completed").

One thing seems strange though: on start (with metadata-process-on-load set) the complete workspace is always rechecked [and I have no clue why the windows environment outputs "Updating: ..." on the way for all files and the linux environment just gives the summary). I think the version from the marketplace found at startup that there is nothing to update and finished quickly.

GitMensch

comment created time in 8 days

CommitCommentEvent

pull request commentlexxmark/winflexbison

Fix build with VS2019

Thank you.

obhi-d

comment created time in 9 days

push eventlexxmark/winflexbison

obhi

commit sha d88c918b54b8a86400478e4627908c97084edc34

Update output.c Update output.c guard inclusion of SDK header by _MSC_VER guard Fix build with VS2019

view details

Simon Sobisch

commit sha bb059e9fd6fad2f958289d87ea0e11cf255c5f6c

Merge pull request #63 from obhi-d/development Fix build with VS2019

view details

push time in 9 days

PR merged lexxmark/winflexbison

Fix build with VS2019

Hello,

With VS2019, currently the following error is generated:

[1/117] Building C object common\CMakeFiles\winflexbison_common.dir\m4\output.c.obj FAILED: common/CMakeFiles/winflexbison_common.dir/m4/output.c.obj C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt\corecrt_io.h(470): error C2375: 'dup_safer': redefinition; different linkage winflexbison\common\m4\lib\unistd-safer.h(20): note: see declaration of 'dup_safer'

Including corecrt_io.h before including m4, which redefines dup as dup_safer, resolves this issue.

-obhi

+3 -1

4 comments

1 changed file

obhi-d

pr closed time in 9 days

pull request commentmsys2/MINGW-packages

Fixed GnuCOBOL 3.1-rc1, please pull to fix a dependency issue

looks like it worked. ship it?

yes, please. I believe all issues with the package for rc1 were solved.

GitMensch

comment created time in 9 days

push eventGitMensch/MINGW-packages

Simon Sobisch

commit sha 21a7959a39261886a3da717479a3eab0230eb852

cjson starts with pkgrel2 to allow its use early (in gnucobol)

view details

push time in 9 days

pull request commentmsys2/MINGW-packages

Fixed GnuCOBOL 3.1-rc1, please pull to fix a dependency issue

CI says:

==> Missing dependencies: -> mingw-w64-x86_64-cjson -> mingw-w64-x86_64-libxml2 -> mingw-w64-x86_64-db

So you suggest that I increase the pkgrel for all those? I think this would be bad as it would update the libxml2 and db package for every user, wouldn't it?

GitMensch

comment created time in 9 days

pull request commentmsys2/MINGW-packages

Fixed GnuCOBOL 3.1-rc1, please pull to fix a dependency issue

CI doesn't find dependencies like mingw-w64-i686-libxml2 or mingw-w64-i686-db which are listed at https://packages.msys2.org/package (it also stumbles over the missing cJSON but this isn't listed in the package list so far).

GitMensch

comment created time in 9 days

Pull request review commentmsys2/MINGW-packages

Fixed GnuCOBOL 3.1-rc1, please pull to fix a dependency issue

 depends=("${MINGW_PACKAGE_PREFIX}-gcc"          "${MINGW_PACKAGE_PREFIX}-gmp"          "${MINGW_PACKAGE_PREFIX}-gettext"          "${MINGW_PACKAGE_PREFIX}-ncurses"+         "${MINGW_PACKAGE_PREFIX}-libxml2"          "${MINGW_PACKAGE_PREFIX}-db")+ # the optional depencies cannot be used for creating the binary packages, moved to depends #optdepends=("${MINGW_PACKAGE_PREFIX}-gettext: support for internationalization" #            "${MINGW_PACKAGE_PREFIX}-ncurses: support for extended screenio"-#            "${MINGW_PACKAGE_PREFIX}-pdcurses: support for screenio")+#            "${MINGW_PACKAGE_PREFIX}-pdcurses: support for screenio"+#            "${MINGW_PACKAGE_PREFIX}-libxml2: support for XML GENERATE")+makedepends=("${MINGW_PACKAGE_PREFIX}-pkg-config")+checkdepends=("${MINGW_PACKAGE_PREFIX}-curl" "${MINGW_PACKAGE_PREFIX}-perl")++# local definitions+CJSON_RELEASE_URL="https://raw.githubusercontent.com/DaveGamble/cJSON/v1.7.13" #source=("https://ftp.gnu.org/gnu/${_realname}/${_realname}-${pkgver}.tar.xz"{,.sig} source=("https://alpha.gnu.org/gnu/${_realname}/${_realname}-${pkgver_real}.tar.xz"{,.sig}         "001-mingw-gnucobol-2.2-fixformatwarnings.patch"-        "cobenv.sh" "cobenv.cmd")+        "002-gnucobol-3.1-rc1-cobol85_crdiff.patch"+        "${CJSON_RELEASE_URL}/cJSON.c"

integrated in the current version (and also removed the checkdepends curl as the external code for make test is now part of the files downloaded via source)

GitMensch

comment created time in 9 days

PullRequestReviewEvent

push eventGitMensch/MINGW-packages

Simon Sobisch

commit sha e82b570cbea4da6b6e3a9ad50f3938c32c260467

GnuCOBOL 3.1rc1.3 pkgrel2 was already public available...

view details

push time in 9 days

push eventGitMensch/MINGW-packages

Christian Meurin

commit sha 87e0aa4935f8bada2aebfa640f8d9956038e6a74

google-resumable-media 0.7

view details

Christian Meurin

commit sha 6267ba5f5003be80766405df9271953a176890da

google-cloud-storage 1.30

view details

Andrew Sun

commit sha c22e57f10a37442c4f87e8ae27698ad4d053771f

json-c: update to 0.15

view details

Christoph Reiter

commit sha 60e1f7e879a2dc5c033005101ab64f52b7c08ee2

Merge pull request #6753 from Adsun701/json-c-0.15 json-c: update to 0.15

view details

Biswapriyo Nath

commit sha c6691ad1bd9d4c6823a18068ca0683c3e32ea005

termcap: add patch to replace write with fprintf(stderr)

view details

Christoph Reiter

commit sha 625370e6b584a0d76367acfb10d1a94f75d51acd

Merge pull request #6756 from Biswa96/termcap-repalce-write-fprintf termcap: add patch to replace write with fprintf(stderr)

view details

HP

commit sha e4c112bc7fc1509fac4f40fc9da176645bd776f1

Update grep to 3.4

view details

Fabien Chouteau

commit sha 2dea73fc34b9c0986198f7c8ed9c6702a98ff442

Rename gprbuild-gpl into gprbuild

view details

Fabien Chouteau

commit sha 41d625f10a2134dc18aa36fdc33a62dd2d9f7c68

Rename xmlada-gpr into xmlada

view details

Fabien Chouteau

commit sha 14fdbd44487a760b2d8b69b70d550b507b03cd5f

Update xmlada This update is required to compile with gcc-ada 10 because of package g-socket incompatible API changes.

view details

Fabien Chouteau

commit sha 0b62d12e709d99e056e1c6a8e32c5070e56f9420

Set fixed commit ids for gprbuild-boostrap-git sources Instead of the latest commit from the master branch.

view details

Christoph Reiter

commit sha e45036c8f730addc200c78c6b8af6a5c01d8b8a2

graphviz: fix the build It's an ancient version, but this is easier than updating. Use a commit hash because the git tag was removed upstream. Build with -fcommon which was the default before gcc 10.

view details

Christoph Reiter

commit sha 727ef7f011bbaa3f8dfe299f206c5a4d70d26694

graphviz: try building without Python not clear if it even needs it

view details

Christoph Reiter

commit sha a60814d54022bd4f1cc3b5d17eb43fa2f108ebc2

Merge pull request #6762 from lazka/graphviz-fix-build graphviz: fix the build

view details

Christoph Reiter

commit sha 18a52d1dcfc9fd536c0f5f2e37fa40aef3f0bac3

Merge pull request #6759 from geant44/master Update grep to 3.4

view details

Christoph Reiter

commit sha 2735a68781cc6eace9533e4166e7c041ccd6b92d

harfbuzz: Update to 2.7.0 revert the cairo dep change since it's now fixed upstream

view details

Jannick

commit sha a648c98dcb818e0536bf0f143397128e4fac61d7

sqlite3: amend configure flag (instead of using patch) * PKGBUILD: - amend configure flag --with-readline-inc (making lemon.patch obsolete) - remove lemon.patch from package source files * lemon.patch: remove file

view details

Jannick

commit sha c0d8a82a664d1419c5a253a83a57349c4b41138a

sqlite3: add soundex() to sqlite3 SQL functions * PKGBUILD: - add CPP flag '-DSQLITE_SOUNDEX=1'

view details

Jannick

commit sha ec86bd30903cfc36c8cdb0bdd8928bf3ad875f6d

sqlite3: cleanup configure feature flags for better maintenance * PKGBUILD: - prefer configure flag '--enable-all' which comprises --enable-json1, --enable-fts4, --enable-fts5 - add configure flag --enable-rtree and remove CPP flag '-DSQLITE_ENABLE_RTREE=1' (NB: In sqlite 3.32.3 --enable-rtree is not implied by --enable-all in contrast to the documentation. Once this bug is fixed --enable-rtree can be removed here.)

view details

Jannick

commit sha f04cff51801b88c139f5af6b2ac63844cd95bb11

sqlite3: add executables dbhash.exe, sqldiff.exe to the package

view details

push time in 9 days

push eventGitMensch/MINGW-packages

Simon Sobisch

commit sha 0ba2f3aea1931e79e972eb103f6d32f0420a96c9

GnuCOBOL 3.1rc1.3 Explicit dependencies, including the new cJSON package, dropped flags that should (and can be) used from MAKEFLAGS.

view details

push time in 9 days

Pull request review commentmsys2/MINGW-packages

Fixed GnuCOBOL 3.1-rc1, please pull to fix a dependency issue

 build() {     #      all generated COBOL modules would be GPLed (and big)...     #      ... and only work when all linked together -  #make -j1   make "--jobs=$(($(nproc)+1))" }  check() {   cd ${srcdir}/build-${CARCH}   # note: strangely multiple tests seem to halt the complete package creation   #make check TESTSUITEFLAGS="--jobs=$(($(nproc)+1))"-  make check+  make check || echo "warning, not all internal tests passed"+  make "--jobs=$(($(nproc)+1))" test || echo "warning, not all NIST tests passed"

Resolved by removing this part as it should not be used here according to the docs. I do wonder if I could pull the amount of jobs used for make out there easily to be used within the TESTSUITEFLAGS....

GitMensch

comment created time in 9 days

PullRequestReviewEvent

pull request commentlexxmark/winflexbison

Fix build with VS2019

Thanks, I saw the error earlier with VS2015, unfortunately did not get time to make the modification.

No problem. I this case you may drop a help wanted note in the future.

I will force push the changes today from my fork.

Sounds good, please drop a note when you've found the time to do so.

obhi-d

comment created time in 9 days

issue commentspgennard/vscode_cobol

problemMatcher: please add code attribute where possible

@spgennard do you prefer to reopen this one or should I create a new one about adding the optional code attribute for the GnuCOBOL problem matchers as outlined above (and originally brought up in the starting post of this issue)?

GitMensch

comment created time in 9 days

issue commentspgennard/vscode_cobol

FR: add localization support to this extension

"Known issue", tracked at https://github.com/microsoft/vscode/issues/54111... and very likely the reason the package description itself is not yet translated in the samples above.

GitMensch

comment created time in 9 days

issue commentmicrosoft/vscode

Localized descriptions for built-in extensions and their settings dont show up in Extensions view

@Colengms said (15 days ago)

Note that this behavior extends to previewing of extensions in the marketplace.

which brings us back to what @sandy081 said 28 months ago:

We can do this only for installed extensions and for non installed ones we do not not have translations. So this will cause some extensions to show translated strings and some does not. We have to be careful with this as users can complain and we cannot support until Market place team supports it or we find a different approach.

So yes, obviously:

  • users do complain, count me in this list
  • users count that as bug, not as a feature-request
  • the only place where this seems to be solvable for the marketplace is to get the market place support translations

What is the state of this? Backlog4ever? This issue has no one assigned from the marketplace team, has it?

ramya-rao-a

comment created time in 9 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

Interesting. Maybe "don't create binaries(--no-bytecode --public --public-packages`) would work, too (no idea if the result could be started as separate process then, but it would very likely allow the external call to work on all systems vscode supports).

GitMensch

comment created time in 9 days

issue commentlexxmark/winflexbison

Can not fix file via --update

You can rename files with an open handle normally fine (all open handles will still be valid), on linux you can additionally delete or overwrite the file (all open handles will still be valid, on Windows the delete/overwrite fails).

But concerning the current issue: discussing with upstream seems reasonable, then likely close, copy, reopen.

voodoo66

comment created time in 9 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

Rechecked 6.9.3 (this time only on windows): still no process spawned, no message anywhere (neither in COBOL nor in Logs) no metadata. Note: the environment with GNU/Linux tested yesterday is exactly identical.

GitMensch

comment created time in 9 days

issue commentspgennard/vscode_cobol

Extension causes high cpu load

6.9.2 feels faster... but should delete and create metadata work with this already?

Metadata cache cleared

Preparing data for external scanner
Scan Data:
 Directories found   : 12
 Directory Depth     : 1
 Files found         : 12438
 Files ignored       : 6311

[checked: no process spawned]

Metadata Dump
 cache_metadata : storagepath

 cache folder             : c:\Users\me\AppData\Roaming\VSCodium\User\workspaceStorage\f00b06fce209b941ff2b9a6714a46820\bitlang.cobol
 Last modified            : 1603174533564.586
 Dirty flag               : false

Global symbols            : (made lowercase)

Paragraphs/Sections in file : none (parse_copybooks_for_references set)

It seems to work fine on linux-x64,

GitMensch

comment created time in 10 days

issue commentspgennard/vscode_cobol

external cobscanner increasing the download size nearly 15 times

Thank you for all those good information. I want to ensure you that I don't create any issue to criticize, but to ask and possibly bring in suggestions.

It was an "issue" for me as (for whatever reason) the download took more than 2 minutes which was quite different to the earlier version and an additional one when seeing the actual binaries which can never target "every system on the world" [it seems most language servers therefore use Java, but spawing many java processes is performance-wise likely not a good idea]. As long as there's a working fallback (which seems to be even feature-identical) everything is fine for me. Side question out of interest: Is there already a note about the use of a fallback in the extension output?

We do have a label "question" here, would you like questions to be asked different than creating an issue in this repo?

They will be no documentation as it is an implementation detail on how the metadata is scanned... who cares if this is an in-process function or an out-of-process feature or a combination of both?

Hm, people that may want to contribute to this repo via code?

GitMensch

comment created time in 10 days

issue commentOlegKunitsyn/gnucobol-debug

test with GnuCOBOL 1.1 / open source COBOL

Any update on this yet?

GitMensch

comment created time in 10 days

issue openedspgennard/vscode_cobol

external cobscanner increasing the download size nearly 15 times

I've just recognized that with the external cobscanner, which was first shipped with https://github.com/spgennard/vscode_cobol/releases/tag/6.8.6 the download size (39.5MB) increased very much, compared to https://github.com/spgennard/vscode_cobol/releases/tag/6.8.5 with 2.65MB. The size difference roots in extension\bin where we have a binary for win32, macos, linux (11-14 MB packed, 35-40MB unpacked).

Questions:

  • Is there any documentation on the external scanner already?
  • What is the external scanner used for?
  • Is it something that is comparable to a language-server?
  • If it is - should it be a separate binary (to limit size and work on more environments, for example ARM is now officially supported even in Visual Studio Code and I guess the currentl linux binary won't work on it)?

created time in 10 days

issue openedmicrosoft/vscode-cpptools

extension preview (marketplace) shows garbage

This is not only related to this extension, but very recognizable with it, so I'm posting it here.

This is what the extension preview looks like: preview

the "garbage descriptions" come from https://github.com/microsoft/vscode-cpptools/blob/master/Extension/package.json and are normally translated at run-time, which isn't possible in the marketplace.

So I do wonder: Should there be two versions of package.json (the original and an additional one created via vscode-nls-dev containing only English strings)? Should the marketplace (server-side) read a second file and send translated strings to the client?

created time in 10 days

issue commentspgennard/vscode_cobol

FR: add localization support to this extension

Yes, that's a very bad user experience. I'll check some MS extensions.

GitMensch

comment created time in 10 days

issue commentspgennard/vscode_cobol

FR: add localization support to this extension

Package.json is expanded on the fly, so the marketplace just shows the unexpanded fields.

Which fields should be translated in the marketplace? The command titles and other descriptions aren't so if in question I'd say just leave whatever the marketplace shows directly in English.

I think_ there's a solution for the second one, most of the extensions that are under MS umbrella use that and I guess webpack is used in one of these, too.

GitMensch

comment created time in 10 days

issue commentspgennard/vscode_cobol

FR: add localization support to this extension

Sample implementation as suggested in another extension: https://github.com/JohnstonCode/svn-scm/pull/1058/files Note: The strings don't need to be manually extracted, https://github.com/Microsoft/vscode-nls-dev can do this.

GitMensch

comment created time in 10 days

issue commentJohnstonCode/svn-scm

Add support to translation

Wanted to suggest the same with explicit "please not use transiflex but plain PRs" - which is exactly what the linked PR does. I'm looking forward to this (and do wonder if it would be possible to at least partially get the data from https://svn.apache.org/repos/asf/subversion/trunk/subversion/po [I think it may be good to mention this under "add a new language" as a hint what wordings a translation should use, at least if in question]).

@JohnstonCode Is there something missing for you to pull this in?

hqzh

comment created time in 10 days

Pull request review commentJohnstonCode/svn-scm

feat: Added translations

 If you use [TortoiseSVN](https://tortoisesvn.net/), make sure the option **Command Line Tools** is checked during installation and `C:\Program Files\TortoiseSVN\bin` is available in PATH. +## Translations+Please open an [issue](https://github.com/JohnstonCode/svn-scm/issues) with improvements to translations or create a [PR](https://github.com/JohnstonCode/svn-scm/pulls) to add a new languate. 

typo: language

JohnstonCode

comment created time in 10 days

PullRequestReviewEvent

issue commentJohnstonCode/svn-scm

How to use SVN in visual studio code

Would a set of videos be nice explaining how to use svn with vscode "from the start" (= for someone neither knowing vscode, nor svn): definitely, but so far I've not seen someone creating them...

I think this is mostly the question how to work with version control in vscode. I suggest to have a look at the common documentation for that, for example https://code.visualstudio.com/Docs/editor/versioncontrol (some parts are git specific but when familiar with svn you'll see those quick). If you are not familiar with SVN, then there are definitely a bunch of videos explaining how to use that.

youssef6dh

comment created time in 10 days

pull request commentVSCodium/vscodium

Custom extensions gallery

... and please use VSCODE_EXTENSIONS_GALLERY_SERVICE_URL and friends.

articlecat

comment created time in 12 days

issue commentVSCodium/vscodium

[PLEASE VOTE] [Discussion] Icon design and/or configuration should be improved

@stripedpajamas I really think the voting can be considered over, can you pull the change-trigger and close this issue, please?

cdata

comment created time in 12 days

pull request commentlexxmark/winflexbison

Fix build with VS2019

@obhi-d Do you mind force-pushing the changes as one commit? As the CI is on "green" now I'd pull them in (but no need for 2 and a half commit for this in the history).

obhi-d

comment created time in 12 days

push eventobhi-d/winflexbison

Simon Sobisch

commit sha fb605cca3f1a21627a79c6a5ec8a7f1a37b3de40

Update output.c

view details

push time in 12 days

push eventobhi-d/winflexbison

Simon Sobisch

commit sha 540a7086536a16b1d65586bb59c3ebd180d4df17

Update output.c guard inclusion of SDK header by _MSC_VER guard

view details

push time in 12 days

PR opened Bill-Gray/PDCursesMod

wincon/wingui: use async PlaySound for PDC_beep fixing #190

partially reverting 78e6949bbd304e3a41bcb687c398a0820b9100a9

I consider an interrupted sound in case of "rapid-fire" better than a "hanging screen i/o"

+3 -3

0 comment

3 changed files

pr created time in 12 days

push eventBill-Gray/PDCursesMod

Simon Sobisch

commit sha 301b7950282983c0566697089632eb35b094c728

wincon/wingui: use async PlaySound for PDC_beep fixing #190 partially reverting 78e6949bbd304e3a41bcb687c398a0820b9100a9

view details

push time in 12 days

create barnchBill-Gray/PDCursesMod

branch : woe32-async-beep

created branch time in 12 days

issue commentBill-Gray/PDCursesMod

WinGUI beep() causing program to pause

I'd guess that the async is no problem (because it is programmer-done when it occurs) but the solution to the "pause issue" while keeping the original solution which was named "beeps to play async" ;-)

rmorales87atx

comment created time in 12 days

issue commentVSCodium/vscodium

Switching between marketplaces

Thanks for the patch, that's very useful and can nearly also applied (or PR'd) to the vscode repo - I still suggest to do so, giving the corporate sample, if it is just "laying" there then VSCodium can use it via your patch (which would be one reason more to prefer VSCodium in business environments). And yes: it solves the marketplace issue, so if/as soon as #537 is merged the wiki page about that should be adjusted.

Thanks again (please consider s/VSCODIUM/VSCODE/g in that patch).

pktiuk

comment created time in 12 days

PullRequestReviewEvent

issue commentLADSoft/OrangeC

CI through Github Actions

Sounds like a reasonable approach!

LADSoft

comment created time in 12 days

more