Page 2 of 4

Re: Request for help in organising/releasing source code

Posted: Sun Sep 16, 2018 5:47 pm
by simonm
Richard Russell wrote:
Sun Sep 16, 2018 4:12 pm
That would certainly be very helpful to me.
As promised then, hopefully it is of some use!

Re: Request for help in organising/releasing source code

Posted: Mon Sep 17, 2018 9:01 am
by Richard Russell
simonm wrote:
Sun Sep 16, 2018 5:47 pm
hopefully it is of some use!
Yes, very interesting. There's one thing I'm not clear about: it states "For any repository you own, only you can make changes to the project" but if the project is added to the 'Stardot GitHub organisation' who can make changes then?

Re: Request for help in organising/releasing source code

Posted: Mon Sep 17, 2018 6:49 pm
by Coeus
Richard Russell wrote:
Mon Sep 17, 2018 9:01 am
simonm wrote:
Sun Sep 16, 2018 5:47 pm
hopefully it is of some use!
Yes, very interesting. There's one thing I'm not clear about: it states "For any repository you own, only you can make changes to the project" but if the project is added to the 'Stardot GitHub organisation' who can make changes then?
I went reading the GitHub documentation. It seems things can be very flexiable but I suspect StarDot have stuck to defaults for many things so a simplified overview....

There are two common "grades" associated with an organisation: owners and members. Owner are like superuser on Unix-like systems. i.e. they can do anything with the organisation account including committing to all its repositories.

Members don't have any special privileges initially, because in a non-paid account all repositories are readable to the general public. However, an owner can assign commit access to one or more repositories to one or more members.

So it does not suddenly become a free-for-all to make changes but it does mean if we could not get hold of you for some time, changes could still be made because owners could either commit directly, possibly in response to a pull request from a member, or could grant a member commit access.

Of course, once you've published the source code there is nothing (technical*) to stop someone else from continuing to develop it independently, usually called "forking" so the question of control over the repository is about control over an "official home". If people do choose to fork it, GitHub provides a button which has the advantage that one can navigate from the original repository to the forks so see what they have been up to.

* I say technical because you could always withhold (reserve) the right to create derived works so doing that would be illegal but obviously that isn't common.

Re: Request for help in organising/releasing source code

Posted: Mon Sep 17, 2018 7:06 pm
by BigEd
Coeus wrote:
Mon Sep 17, 2018 6:49 pm
... you could always withhold (reserve) the right to create derived works ...
Might be worth noting that this is the default: things can't be copied unless the creator says they can be copied. For this reason it's really helpful to add a suitable license to your project or your source files.
Richard Russell wrote:
Wed Sep 12, 2018 6:42 pm
My objective is simply to put it into the public domain, so that it doesn't vanish when I die...
I'd suggest in this case choosing the CC0 license.

It should be understood - and probably already is, but here we go - that merely putting code in a public place, even github, does not change its copyright or licensing status, and does not put it in the public domain. There are people who would prefer not to have to even think about this kind of thing, who don't want to be bothered with 'legal stuff' - I understand the position, but to make it work you have to do something. CC0 is as close as you can get, sensibly, to saying 'do anything'. (There are other approaches but they are not nearly as useful.)

Re: Request for help in organising/releasing source code

Posted: Mon Sep 17, 2018 7:33 pm
by Richard Russell
BigEd wrote:
Mon Sep 17, 2018 7:06 pm
CC0 is as close as you can get, sensibly, to saying 'do anything'.
Since BBCSDL is so dependent on (and linked with, in some editions) SDL, there's an argument that using the same licence (zlib) would be sensible; I have no idea how it compares with CC0. But at the moment I can't see how putting my project on GitHub would achieve anything other than making my life more difficult than it is now! I can see the value to collaborative projects, but over the years I've asked over and over again for people to help me develop BBC BASIC, and nobody ever has.

Re: Request for help in organising/releasing source code

Posted: Mon Sep 17, 2018 7:53 pm
by BigEd
Having a project out in the open is a step towards getting contributors. It might not happen very soon, but it has every chance of happening. Seeing the code and wanting to work on it is a stimulus.

The zlib license would also be a reasonable choice. But choosing anything that's more permissive would serve the same end of interoperability - and CC0 is as permissive as they come.

Re: Request for help in organising/releasing source code

Posted: Mon Sep 17, 2018 9:41 pm
by Richard Russell
BigEd wrote:
Mon Sep 17, 2018 7:53 pm
Having a project out in the open is a step towards getting contributors. It might not happen very soon, but it has every chance of happening.
If it does happen it will probably be too late to be a 'collaboration' (with me, anyway!) because by then I expect I will either not be around any more, or not able to contribute in a useful way. :(

Releasing the source as a zip may not be as sophisticated as putting it on GitHub, but it has achieved what I set out to. Incidentally I have today updated the file to match the latest release of BBCSDL. The changes are as follows:
  1. The line-editor used by the INPUT and INPUT LINE statements (and in immediate mode) has been enhanced to support UTF-8.
  2. The socklib.bbc library now supports UDP as well as TCP.
  3. A new library utf8lib.bbc has been added with UTF-8 replacements for LEFT$, RIGHT$, MID$, INSTR and LEN.
  4. David Williams' 'Rainbow Snake' program has been added to the examples.
  5. A new example program 'lanchat.bbc' demonstrates the use of UDP for a serverless chat application.
For those not familiar with BB4W and BBCSDL UTF-8 support can be enabled using the VDU 23,22.... custom mode command. In conjunction with a suitable font this allow BBC BASIC to work with extended character sets (see unicode.bbc in the supplied examples).

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 10:06 am
by simonm
Richard Russell wrote:
Mon Sep 17, 2018 9:41 pm
Releasing the source as a zip may not be as sophisticated as putting it on GitHub, but it has achieved what I set out to.
Absolutely, and a perfectly fine way to do it - entirely your prerogative how you want to distribute your own projects.
That said, you might wish to consider putting some type of license file into your source zip package, so that there's some means for you to specify terms of use.

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 11:38 am
by Richard Russell
simonm wrote:
Tue Sep 18, 2018 10:06 am
That said, you might wish to consider putting some type of license file into your source zip package
I've added the zlib licence, FWIW, although one of the few benefits of getting 'old' is that how one's software might or might not get used in the future is of little concern! I don't have any children or heirs who might care either.

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 11:53 am
by davidb
My impression was that there are quite a few avid users of BBC BASIC for SDL and Windows, so you may find that one or more of them might be interested in helping with the language implementation. After all, the users are often the ones driving development. :)

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 12:22 pm
by dhg2
over the years I've asked over and over again for people to help me develop BBC BASIC, and nobody ever has.
Now that there's source code available, there's an increased chance that people will start helping out in the future, as BigEd said.

Have you put a link to the source code zip archive on the BBCSDL webpage? I had a look but couldn't find it there. I'd suggest adding it there so your users who may not browse any forums can find it.

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 1:07 pm
by Richard Russell
davidb wrote:
Tue Sep 18, 2018 11:53 am
My impression was that there are quite a few avid users of BBC BASIC for SDL and Windows, so you may find that one or more of them might be interested in helping with the language implementation. After all, the users are often the ones driving development. :)
Experience has shown it not to be the case. I suspect the main factor is the 'age profile' of the users of BB4W and BBCSDL: they tend to be in my age bracket or older (sometimes much older!).

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 1:36 pm
by Richard Russell
dhg2 wrote:
Tue Sep 18, 2018 12:22 pm
Have you put a link to the source code zip archive on the BBCSDL webpage?
Not as yet, no. I'm uneasy about drawing attention to a source package that isn't actually used to build the BBCSDL releases (with the exception of the Raspberry Pi edition, which was built from those sources this time), for fear of misleading people. At the moment keeping that source zip in sync with releases is an entirely manual process.

Over time I'll transition the Android and iOS editions to use the published sources (I'm very risk averse!) but the 32-bit x86 editions (Windows, Linux, MacOS) will continue to be built from the old sources, because of the speed benefit (something like x2) and the presence of an assembler.

Has anybody actually tried to build a working executable from the sources I published?

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 3:26 pm
by bakoulis
I tried to build on my Linux Mint 17.3 32-bit but it fails with errors.

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 4:16 pm
by dhg2
bakoulis wrote:
Tue Sep 18, 2018 3:26 pm
I tried to build on my Linux Mint 17.3 32-bit but it fails with errors.
It builds and runs on my laptop with Debian stable AMD64. Which errors did you get?

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 4:42 pm
by Richard Russell
bakoulis wrote:
Tue Sep 18, 2018 3:26 pm
I tried to build on my Linux Mint 17.3 32-bit but it fails with errors.
I haven't included a 32-bit Linux makefile in the zip! Did you realise that and make the necessary changes first? I assumed that 32-bit Linux was so rare that there was little point including a suitable makefile (is there a way of detecting 32/64 bits so the makefile could be 'universal'?).

Re: Request for help in organising/releasing source code

Posted: Tue Sep 18, 2018 9:28 pm
by bakoulis
So, the problem was expected!
You haven't included makefile for 32bit linux or an universal makefile with 32/64 detection!
And I can't make changes on makefile myself.

Re: Request for help in organising/releasing source code

Posted: Wed Sep 19, 2018 12:31 am
by scruss
Richard Russell wrote:
Tue Sep 18, 2018 4:42 pm
(is there a way of detecting 32/64 bits so the makefile could be 'universal'?).
From the shell

Code: Select all

getconf LONG_BIT
returns 32 or 64. From a Makefile, I do not know how.

Re: Request for help in organising/releasing source code

Posted: Wed Sep 19, 2018 8:51 pm
by Coeus
bakoulis wrote:
Tue Sep 18, 2018 9:28 pm
And I can't make changes on makefile myself.
Because you don't know how to or because you fear it is not allowed? Ricard is releasing this under the zlib license so you are allowed to alter the makefike or create a parallel one for 32 bit.

Re: Request for help in organising/releasing source code

Posted: Wed Sep 19, 2018 8:58 pm
by Coeus
Richard Russell wrote:
Tue Sep 18, 2018 1:36 pm
Has anybody actually tried to build a working executable from the sources I published?
It builds and runs on Arch Linux 64, as in it starts, lunches the IDE and would run a short type-in and a couple of others I had to hand.

In that respect this is an advance on the 32 bit package from the website which crashes inside SDL even with the 32 bit libraries installed.

Even if it was no better, now I would be able to debug it more easily and, if it turned out to be a libSDL bug, send in a bjg report to them that makes sense.

Re: Request for help in organising/releasing source code

Posted: Wed Sep 19, 2018 9:59 pm
by Richard Russell
Coeus wrote:
Wed Sep 19, 2018 8:58 pm
In that respect this is an advance on the 32 bit package from the website which crashes inside SDL even with the 32 bit libraries installed.
When you say "crashes" can you confirm that you're not talking about the D-Bus error referred to in the install.txt file? As it states there, on some systems you must execute 32-bit BBCSDL using:

Code: Select all

IBUS_ADDRESS=0 ./bbcsdl
If you're doing that and it still crashes, what error message are you receiving?

Re: Request for help in organising/releasing source code

Posted: Wed Sep 19, 2018 10:37 pm
by Richard Russell
scruss wrote:
Wed Sep 19, 2018 12:31 am
From the shell

Code: Select all

getconf LONG_BIT
OK, I have updated the Linux makefile to adapt automatically and it should now build a 32-bit or 64-bit executable successfully depending on the platform. However you may still need to run the 32-bit version using:

Code: Select all

IBUS_ADDRESS=0 ./bbcsdl
as documented here. I'm not aware that this issue is receiving much attention from SDL developers, perhaps because of the relative rarity of 32-bit Linux. Also, please be aware that the 32-bit executable available for download from the website contains an x86-32 assembler, whereas what you can build yourself from the sources doesn't (and runs at about half the speed).

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 7:12 am
by BigEd
Richard Russell wrote:
Wed Sep 19, 2018 10:37 pm
... you may still need to run the 32-bit version using:

Code: Select all

IBUS_ADDRESS=0 ./bbcsdl
BTW, a portability tip, as people may run different shells. This syntax is acceptable to all shells, AFAIK:

Code: Select all

env IBUS_ADDRESS=0 ./bbcsdl

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 8:19 am
by bakoulis
Still I can't build from source on 32bit linux.
I suspect the problem is from use of bbasmb_x86_64 assembler inside makefile.
If you need more, I can provide you the log with errors.
:(

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 5:20 pm
by Coeus
Richard Russell wrote:
Wed Sep 19, 2018 9:59 pm
When you say "crashes" can you confirm that you're not talking about the D-Bus error referred to in the install.txt file?
The workaround for that bug does not help. Here's the backtrace:

Code: Select all

Thread 1 "bbcsdl" received signal SIGSEGV, Segmentation fault.
0xf603e60a in ?? () from /usr/lib32/dri/i965_dri.so
(gdb) bt
#0  0xf603e60a in ?? () from /usr/lib32/dri/i965_dri.so
#1  0xf603e8ae in ?? () from /usr/lib32/dri/i965_dri.so
#2  0xf6040365 in ?? () from /usr/lib32/dri/i965_dri.so
#3  0xf60780de in ?? () from /usr/lib32/dri/i965_dri.so
#4  0xf6069e44 in ?? () from /usr/lib32/dri/i965_dri.so
#5  0xf61272c0 in ?? () from /usr/lib32/dri/i965_dri.so
#6  0xf613848b in ?? () from /usr/lib32/dri/i965_dri.so
#7  0xf61397c5 in ?? () from /usr/lib32/dri/i965_dri.so
#8  0xf5b87081 in ?? () from /usr/lib32/dri/i965_dri.so
#9  0xf5bc057d in ?? () from /usr/lib32/dri/i965_dri.so
#10 0xf5bbb541 in ?? () from /usr/lib32/dri/i965_dri.so
#11 0xf5cc53ae in ?? () from /usr/lib32/dri/i965_dri.so
#12 0xf5bc38aa in ?? () from /usr/lib32/dri/i965_dri.so
#13 0xf5cc6ae7 in ?? () from /usr/lib32/dri/i965_dri.so
#14 0xf5cc6e79 in ?? () from /usr/lib32/dri/i965_dri.so
#15 0xf7e55ddc in ?? () from /usr/lib32/libSDL2-2.0.so.0
#16 0xf7e534f9 in ?? () from /usr/lib32/libSDL2-2.0.so.0
#17 0x565683b1 in error ()
#18 0x5677d040 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 5:52 pm
by Richard Russell
Coeus wrote:
Thu Sep 20, 2018 5:20 pm
The workaround for that bug does not help.
I'm really confused now. You are definitely receiving this error message: "arguments to dbus_message_new_method_call() were incorrect", is that right? And the workaround for that bug given at the SDL forum isn't helping? The confusing thing is that you showed a SIGSEGV fault which, at first sight, is unrelated to the Dbus error.

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 5:59 pm
by Richard Russell
bakoulis wrote:
Thu Sep 20, 2018 8:19 am
I suspect the problem is from use of bbasmb_x86_64 assembler inside makefile.
But it shouldn't be used! I've added code to the makefile (which Google found) that tests whether your platform is 32 or 64-bits and assembles the appropriate file. If your system is 32-bits, which I think you said it was, the file that it should be assembling is bbdata_x86_32.nas not bbdata_x86_64.nas:

Code: Select all

ifeq ($(LBITS),64)
bbdata.o: ../../src/bbdata_x86_64.nas
	nasm -f elf64 -s ../../src/bbdata_x86_64.nas -o bbdata.o
else
bbdata.o: ../../src/bbdata_x86_32.nas
	nasm -f elf32 -s ../../src/bbdata_x86_32.nas -o bbdata.o
endif

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 6:29 pm
by Coeus
Richard Russell wrote:
Thu Sep 20, 2018 5:52 pm
I'm really confused now. You are definitely receiving this error message: "arguments to dbus_message_new_method_call() were incorrect", is that right?
No I do not receive that error message and yes, I believe this is a completely different issue. Upon starting bbcsdl the "Choose IDE" window appears briefly, with no content, and then, if not running under gdb, the shell reports: "Segmentation fault (core dumped)". With gdb I can obviously ask for a stack trace but as neither bbcsdl, the SDL library, or the i965 driver are compiled with debugging symbols it isn't that helpful.

If I build both SDL and lib32-mesa with debugging symbols I get:

Code: Select all

Thread 1 "bbcsdl" received signal SIGSEGV, Segmentation fault.
0xf603d60a in brw_inst_set_bits (value=<optimized out>, low=25, high=25, 
    inst=0x56959b78) at ../mesa-18.2.0/src/intel/compiler/brw_inst.h:1001
1001	../mesa-18.2.0/src/intel/compiler/brw_inst.h: No such file or directory.
(gdb) bt
#0  0xf603d60a in brw_inst_set_bits (value=<optimized out>, low=25, high=25, 
    inst=0x56959b78) at ../mesa-18.2.0/src/intel/compiler/brw_inst.h:1001
#1  brw_inst_set_flag_subreg_nr (devinfo=<optimized out>, 
    value=<optimized out>, inst=0x56959b78)
    at ../mesa-18.2.0/src/intel/compiler/brw_inst.h:173
#2  brw_inst_set_state (state=0x5695508c, insn=0x56959b78, 
    devinfo=<optimized out>)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:543
#3  brw_next_insn (p=0x56955078, opcode=64)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:571
#4  0xf603d8ae in brw_alu2 (p=p@entry=0x56955078, opcode=opcode@entry=64, 
    dest=..., src0=..., src1=...)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:594
#5  0xf603f365 in brw_ADD (p=0x56955078, dest=..., src0=..., src1=...)
    at ../mesa-18.2.0/src/intel/compiler/brw_eu_emit.c:969
#6  0xf60770de in fs_generator::generate_code (this=0xffffb10c, 
    cfg=0x5691c968, dispatch_width=8)
    at ../mesa-18.2.0/src/intel/compiler/brw_fs_generator.cpp:1865
#7  0xf6068e44 in brw_compile_fs (compiler=<optimized out>, 
    log_data=<optimized out>, mem_ctx=<optimized out>, key=<optimized out>, 
    prog_data=<optimized out>, src_shader=<optimized out>, 
    prog=<optimized out>, shader_time_index8=<optimized out>, 
    shader_time_index16=<optimized out>, shader_time_index32=<optimized out>, 
--Type <RET> for more, q to quit, c to continue without paging--
    allow_spilling=<optimized out>, use_rep_send=<optimized out>, 
    vue_map=<optimized out>, error_str=<optimized out>)
    at ../mesa-18.2.0/src/intel/compiler/brw_fs.cpp:7245
#8  0xf61262c0 in blorp_compile_fs (blorp=<optimized out>, 
    mem_ctx=<optimized out>, nir=0x565dfa28, wm_key=<optimized out>, 
    use_repclear=<optimized out>, wm_prog_data=<optimized out>)
    at ../mesa-18.2.0/src/intel/blorp/blorp.c:206
#9  0xf613748b in brw_blorp_get_blit_kernel (prog_key=0xffffc9f4, 
    params=<optimized out>, blorp=0x5661a180)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:1453
#10 try_blorp_blit (coords=0xffffc04c, wm_prog_key=0xffffc9f4, 
    params=0xffffc35c, batch=0xffffd0c4)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:2039
#11 do_blorp_blit (batch=batch@entry=0xffffd0c4, 
    orig_params=orig_params@entry=0xffffca5c, 
    wm_prog_key=wm_prog_key@entry=0xffffc9f4, orig=0xffffc9ac)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:2181
#12 0xf61387c5 in blorp_copy (batch=0xffffd0c4, src_surf=0xffffd0d0, 
    src_level=0, src_layer=0, dst_surf=0xffffd124, dst_level=0, dst_layer=0, 
    src_x=<optimized out>, src_y=<optimized out>, dst_x=<optimized out>, 
    dst_y=<optimized out>, src_width=<optimized out>, 
    src_height=<optimized out>)
    at ../mesa-18.2.0/src/intel/blorp/blorp_blit.c:2654
--Type <RET> for more, q to quit, c to continue without paging--
#13 0xf5b86081 in brw_blorp_copy_miptrees (brw=0x5660cc58, src_mt=0x56602a20, 
    src_level=<optimized out>, src_layer=0, dst_mt=0x569130d0, 
    dst_level=<optimized out>, dst_layer=0, src_x=0, src_y=0, dst_x=0, 
    dst_y=0, src_width=540, src_height=439)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/brw_blorp.c:517
#14 0xf5bbf57d in intel_miptree_map_blit (slice=0, level=0, map=0x5691c380, 
    mt=0x56602a20, brw=0x5660cc58)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:3104
#15 intel_miptree_map (brw=0x5660cc58, mt=0x56602a20, level=0, slice=0, x=0, 
    y=0, w=540, h=439, mode=1, out_ptr=0xffffd2a0, out_stride=0xffffd2a4)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:3626
#16 0xf5bba541 in intel_map_renderbuffer (ctx=0x5660cc58, rb=0x56602430, x=0, 
    y=<optimized out>, w=540, h=439, mode=1, out_map=0xffffd340, 
    out_stride=0xffffd33c, flip_y=true)
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_fbo.c:170
#17 0xf5cc43ae in read_rgba_pixels (packing=0xffffd458, pixels=0xe2a59010, 
    type=33639, format=32993, height=439, width=540, y=0, x=0, ctx=0x5660cc58)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:464
#18 _mesa_readpixels (ctx=0x5660cc58, x=0, y=0, width=540, height=439, 
    format=32993, type=33639, packing=0xffffd458, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:896
#19 0xf5bc28aa in intelReadPixels (ctx=0x5660cc58, x=0, y=0, width=540, 
    height=439, format=32993, type=33639, pack=0xffffd458, pixels=0xe2a59010)
--Type <RET> for more, q to quit, c to continue without paging--
    at ../mesa-18.2.0/src/mesa/drivers/dri/i965/intel_pixel_read.c:296
#20 0xf5cc5ae7 in read_pixels (no_error=false, pixels=0xe2a59010, 
    bufSize=2147483647, type=33639, format=32993, height=<optimized out>, 
    width=<optimized out>, y=<optimized out>, x=<optimized out>)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1136
#21 _mesa_ReadnPixelsARB (x=0, y=0, width=540, height=439, format=32993, 
    type=33639, bufSize=2147483647, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1153
#22 0xf5cc5e79 in _mesa_ReadPixels (x=0, y=0, width=540, height=439, 
    format=32993, type=33639, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1168
#23 0xf7e54ddc in ?? () from /usr/lib32/libSDL2-2.0.so.0
#24 0xf7e524f9 in ?? () from /usr/lib32/libSDL2-2.0.so.0
#25 0x565683b1 in error ()
#26 0x5678eee0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 
Still no reporting of which function in the SDL library!

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 7:14 pm
by Richard Russell
Coeus wrote:
Thu Sep 20, 2018 6:29 pm
No I do not receive that error message
OK, I was confused by your comment "The workaround for that bug does not help" because it seemed to imply you were.
With gdb I can obviously ask for a stack trace but as neither bbcsdl, the SDL library, or the i965 driver are compiled with debugging symbols
You can easily compile BBCSDL with symbols if you want to, it's your choice. But the stack trace seemed to imply it is crashing in 'i965_dri.so' which according to Google is something to do with mesa. If I've understood you correctly it's a 64-bit system on which the 64-bit build of BBCSDL runs but the 32-bit build doesn't, despite the i386 architecture being installed. Given that 32-bit BBCSDL runs correctly on Android and the Raspberry Pi (and here on 32-bit Ubuntu) it seems unlikely that the fault is in my code.

Re: Request for help in organising/releasing source code

Posted: Thu Sep 20, 2018 8:22 pm
by Coeus
Richard Russell wrote:
Thu Sep 20, 2018 7:14 pm
You can easily compile BBCSDL with symbols if you want to, it's your choice....
It seems in the last trace compiling with debug symbols didn't do anything for libSDL because I needed to rebuild libSDL2 instead. This makes the last few lines:

Code: Select all

#22 0xf5cb9e79 in _mesa_ReadPixels (x=0, y=0, width=540, height=439, 
    format=32993, type=33639, pixels=0xe2a59010)
    at ../mesa-18.2.0/src/mesa/main/readpix.c:1168
#23 0xf7e53cac in GL_RenderReadPixels (renderer=0x567c5ef0, rect=0xffffd5a8, 
    pixel_format=390076419, pixels=0xe2b41046, pitch=1624)
    at /usr/src/debug/SDL2-2.0.8/src/render/opengl/SDL_render_gl.c:1539
#24 0xf7e513c9 in SDL_RenderReadPixels_REAL (renderer=0x567c5ef0, 
    rect=0xffffd61c, format=390076419, pixels=0xe2b41046, pitch=1624)
    at /usr/src/debug/SDL2-2.0.8/src/render/SDL_render.c:2017
#25 0x565683b1 in error ()
#26 0x567c5ef0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
If I try it on a machine with Radeon rather than Intel graphics I instead get an error "Unable to initialise UDEV" in a dialogue box.