gnupic: Thread: Re: [gnupic] Gtk-CRITICAL in GUI gpsim

On Saturday 29 July 2006 08:30, Nestor A. Marchesini wrote:
> Hi..I have a problem with gpsim, 

You'd be better asking on  the GPSim list, so I've CC'd this reply.

>  From the terminal I can simulate without problems, but from the
> graphical GUI It displeases
> the line to executing (showed with the black arrow) with regard to the
> line of code that is
> executed really, the message that gives me is the following one:
>
> [nestor@deselectronica test]$ gpsim -s test.cod
>
> gpsim - the GNUPIC simulator
> version: Release 0.21.12-pre
>
>
> type help for help
> **gpsim> SimulationMode:82
> No long symbol table info
> FIXME:  HLL files are not supported at the moment
> SSPADD in unimplemented, as is all of I2C.
>
> (gpsim:13571): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion
> `g_utf8_validate (text, len, NULL)' failed
>
> That will be happening?
>
Which versions of GTK+ and GTK-extra are you using?
I have GTK+ 2.8.19 and GTKextra 2.1.1
Old versions had incompatibilities and will not work with GPSim.

That said, the current PC marker does sometimes get offset for other reasons, 
such as the COD file having been built from a different version of the 
source. The release version of gplink has some defects in the reporting of 
line numbers when multiple source files and multiple code sections are used, 
which also causes similar errors on the GPSim display.

Hope that helps,
Rob Pearce

Hi Rob
ok, thanks for answering, I will bear in mind the GPSim list.
These are the versions that I have installed:

[nestor@deselectronica ~]$ pkg-config --modversion gtk+-2.0
2.8.3
[nestor@deselectronica ~]$ pkg-config --modversion gtkextra-2.0
2.1.1
[nestor@deselectronica ~]$ pkg-config --modversion gtk+
1.2.10

./configure gives the following message:

checking for pkg-config... /usr/bin/pkg-config
linking with gtk-2.8.3

make uses the following things

g++ -DHAVE_CONFIG_H -I. -I. -I.. 
-I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0
-I/usr/include/cairo
-I/usr/include/pango-1.0
-I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include
-g -O2 -MT scan.lo -MD -MP -MF
.deps/scan.Tpo -c scan.cc  -fPIC -DPIC -o .libs/scan.o

now if I execute gtk-config and gtkextra-config gives:

[nestor@deselectronica ~]$ gtk-config --version
1.2.10
[nestor@deselectronica ~]$ gtkextra-config --version
0.99.17

I believe that it does not affect that has installed gtk 1.2.10 and 
gtkextra 0.99.17.
I expect not to disturb the gnupic list with this email.

Regards

Néstor A. Marchesini
Chajari-Entre Rios-Argentina
ICQ # 50983752 colo
MSN ####@####.####
####@####.####
####@####.####
http://www.deselectronica.com.ar

Rob Pearce escribió:

>On Saturday 29 July 2006 08:30, Nestor A. Marchesini wrote:
>
>>Hi..I have a problem with gpsim, 
>>
>
>You'd be better asking on  the GPSim list, so I've CC'd this reply.
>
>>From the terminal I can simulate without problems, but from the
>>graphical GUI It displeases
>>the line to executing (showed with the black arrow) with regard to the
>>line of code that is
>>executed really, the message that gives me is the following one:
>>
>>[nestor@deselectronica test]$ gpsim -s test.cod
>>
>>gpsim - the GNUPIC simulator
>>version: Release 0.21.12-pre
>>
>>
>>type help for help
>>**gpsim> SimulationMode:82
>>No long symbol table info
>>FIXME:  HLL files are not supported at the moment
>>SSPADD in unimplemented, as is all of I2C.
>>
>>(gpsim:13571): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion
>>`g_utf8_validate (text, len, NULL)' failed
>>
>>That will be happening?
>>
>hich versions of GTK+ and GTK-extra are you using?
>I have GTK+ 2.8.19 and GTKextra 2.1.1
>Old versions had incompatibilities and will not work with GPSim.
>
>That said, the current PC marker does sometimes get offset for other reasons, 
>such as the COD file having been built from a different version of the 
>source. The release version of gplink has some defects in the reporting of 
>line numbers when multiple source files and multiple code sections are used, 
>which also causes similar errors on the GPSim display.
>
>Hope that helps,
>Rob Pearce
>

On Mon, 31 Jul 2006, Nestor A. Marchesini ####@####.#### wrote :
>These are the versions that I have installed:
>
>[nestor@deselectronica ~]$ pkg-config --modversion gtk+-2.0
>2.8.3

I think that should be OK, but I can't remember where the actual cut-off 
was. Certainly 2.8.8 worked. It may be worth trying to upgrade that and 
see if it helps.

>
>I believe that it does not affect that has installed gtk 1.2.10 and 
>gtkextra 0.99.17.

It shouldn't, but it might. In particular, I got bitten by gtkextra 
having both versions present and picking up the wrong one at run time. 
As I recall it was to do with .pc files not being found properly by 
pkg-config (which you don't seem to suffer from) but I may be 
mis-remembering.

>I expect not to disturb the gnupic list with this email.

'fraid you did, but I wouldn't worry - I'd much rather try to answer 
this on the list, because knowledgeable people might spot it if I go 
wrong.
-- 
Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of this | All the men on my staff can type.
message are purely   |  -- Bella Abzug
my opinion. Don't    |
believe a word.      |

Hi Robert
I have solved the problem.

(gpsim:13571): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: 
assertion`g_utf8_validate (text, len, NULL)' failed

The problem they were not the GTK, It was in my locale, I use es_AR.UTF-8

[nestor@deselectronica ~]$ locale
LANG=es_AR.UTF-8
LC_CTYPE=es_AR.UTF-8
LC_NUMERIC=es_AR.UTF-8
LC_TIME=es_AR.UTF-8
LC_COLLATE=es_AR.UTF-8
LC_MONETARY=es_AR.UTF-8
LC_MESSAGES=es_AR.UTF-8
LC_PAPER=es_AR.UTF-8
LC_NAME=es_AR.UTF-8
LC_ADDRESS=es_AR.UTF-8
LC_TELEPHONE=es_AR.UTF-8
LC_MEASUREMENT=es_AR.UTF-8
LC_IDENTIFICATION=es_AR.UTF-8
LC_ALL=

[nestor@deselectronica ~]$ locale charmap
UTF-8

To change the locale in Mandriva2007 it is possible to use drakconf.

The spanish language, there uses the codification of characters ISO-8859-1
and the spanish with the symbol of the euro (EUR) the ISO-8859-15.
My original code was in ISO-8859-1 and it turns out that my linux 
Mandriva2007
for default is UTF-8, in short, the problem they were the accents used 
in the
commentaries of my code.
Now I use iconv to turn of format and the probema disappeared completely.

I to want to be grateful on a post in the last days, since I have 
Mandriva2007
and it had the same problem of which on having wanted to change the size of
window of the RAM memory and of the window EEPROM memory it was closed gpsim
giving me a violation of segment.
Unload the libary gtk+extra-2.1.1.tar.gz and to modify the line 4152 as says
in the link passed and I can say this it was exactly the problem since now
gpsim it me works perfectly.
The steps were: 

[nestor@deselectronica ~]$ tar /xvfz /gtk+extra-2.1.1.tzr.gz
[nestor@deselectronica ~]$ cd gtk+extra-2.1.1
[nestor@deselectronica ~]$ cd gtkextra
[nestor@deselectronica ~]$ cooledit --look cool gtksheet.c
change g_free(sheet->pixmap)
to     g_object_unref(sheet->pixmap)
[nestor@deselectronica ~]$ ./configure
[nestor@deselectronica ~]$ make
[nestor@deselectronica ~]$ su
[root@deselectronica nestor]# make install
[root@deselectronica nestor]# cp 
/usr/local/lib/pkgconfig/gtkextra-2.0.pc /usr/lib/pkgconfig
[root@deselectronica nestor]# cooledit --look cool /etc/ld.so.conf
add a line at the end with:
/usr/local/lib
[root@deselectronica nestor]# ldconfig
[root@deselectronica nestor]# exit

[nestor@deselectronica ~]$ tar xvfz gpsim-0.22.0.tzr.gz
[nestor@deselectronica ~]$ cd gpsim-0.22.0
[nestor@deselectronica ~]$ ./configure --enable-sockets
[nestor@deselectronica ~]$ make
[nestor@deselectronica ~]$ su
[root@deselectronica nestor]# make install
[root@deselectronica nestor]# ldconfig
[root@deselectronica nestor]# exit

 From already thank yours and I hope that this commentary serves someone.

Regards

Néstor A. Marchesini
Chajari-Entre Rios-Argentina
ICQ # 50983752 colo
MSN ####@####.####
####@####.####
####@####.####
http://www.deselectronica.com.ar

Rob Pearce escribió:
> On Saturday 29 July 2006 08:30, Nestor A. Marchesini wrote:
>> Hi..I have a problem with gpsim, 
>
> You'd be better asking on  the GPSim list, so I've CC'd this reply.
>
>>  From the terminal I can simulate without problems, but from the
>> graphical GUI It displeases
>> the line to executing (showed with the black arrow) with regard to the
>> line of code that is
>> executed really, the message that gives me is the following one:
>>
>> [nestor@deselectronica test]$ gpsim -s test.cod
>>
>> gpsim - the GNUPIC simulator
>> version: Release 0.21.12-pre
>>
>>
>> type help for help
>> **gpsim> SimulationMode:82
>> No long symbol table info
>> FIXME:  HLL files are not supported at the moment
>> SSPADD in unimplemented, as is all of I2C.
>>
>> (gpsim:13571): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion
>> `g_utf8_validate (text, len, NULL)' failed
>>
>> That will be happening?
>>
> Which versions of GTK+ and GTK-extra are you using?
> I have GTK+ 2.8.19 and GTKextra 2.1.1
> Old versions had incompatibilities and will not work with GPSim.
>
> That said, the current PC marker does sometimes get offset for other reasons, 
> such as the COD file having been built from a different version of the 
> source. The release version of gplink has some defects in the reporting of 
> line numbers when multiple source files and multiple code sections are used, 
> which also causes similar errors on the GPSim display.
>
> Hope that helps,
> Rob Pearce

Whereas in commentaries it is not a problem to use characters UTF-8 it is
not possible to use characters that know that they have two bytes in UTF-8
together with the nemónicos..
My problem was on having tried to use:

  movlw A'Ñ'
  xorwf ReceiveRS232,W
  skpnz
  goto  AreEquals
  ...

The Ñ capital letter codified in UTF-8 has two bytes (H'C3'H'D1')
and codified in ISO-8859-1 has a byte alone (H'D1'), my code was
not walking since me the byte was never coinciding received for
RS232 H'D1' with the first byte fixed in UTF-8 by means of movlw A'Ñ'
that is H'C3'.
The solution was to change to:

 movlw H'D1'

The question of the million:
There is some way of saying to glib/gtk that they should use iso-8859-1
instead of UTF-8 on having run gpsim?

I have read thereabouts, that putting something like:

~$ G_FILENAME_ENCODING=ISO-8859-1 <program>

that one was forcing to the program in question to use iso-8859-1.
On programming with glib/gtk deal very little, but for what I read,
so many glib since as gtk try internally in UTF-8.

Regards

Néstor A. Marchesini
Chajari-Entre Rios-Argentina
ICQ # 50983752 colo
MSN ####@####.####
####@####.####
####@####.####
http://www.deselectronica.com.ar

Nestor A. Marchesini wrote:
> Whereas in commentaries it is not a problem to use characters UTF-8 it is
> not possible to use characters that know that they have two bytes in UTF-8
> together with the nemónicos..
> My problem was on having tried to use:
> 
>  movlw A'Ñ'
>  xorwf ReceiveRS232,W
>  skpnz
>  goto  AreEquals
>  ...

Néstor,

If you can send me a small program that exposes this problem, I'll try 
it out and see if I can fix gpsim's behavior.

Scott

Hi Scott
Maybe I explained badly and with the urgency in sending the email I have 
not changed the matter ... my excuses.
My code receives several commands codified in ASCII from the letter A to 
the letter S, all in capital letters included the letter Ñ that is not 
included inside the first 127 characters ASCII.
In the spanish language the letters of the alphabet are:

A B C D E F G H I J K L M N Ñ O P Q R S T U V W X Y Z

Innocently I used the letter Ñ for a command, but then I find out that 
in my new linux mandriva2007 for default
use UTF-8, for which elegantly the boys of mandriva have put a scrit in 
perl in your FAQ that turns the names of folders and files from 
iso-8859-1 or iso-8859-15 to UTF-8.

Therefore this one was not a fault in gpsim or in gpasm, rather the 
problem I had it with the combination of my editor cooledit (the 
fabulous editor cooledit of Paul Sheer) on having used movlw A'Ñ'.
Cooledit has the option to interpret UTF-8 and to show characters out of 
the locale selected in the system,
but if does not know one like well these two functions work in cooledit, 
is for confusion.
The matter is that to the assemble movlw 'Ñ', gpasm I was giving error, 
then I was
removing the H'D1' and stopping H'C3', believing that H'C3' was the 
character of the
letter Ñ, when really it is upside-down .. the whole confusion for not 
dealing like there works the codification UTF-8.
Now and for compatibility with ASCII I have eliminated the command Ñ.
For if there is someone who still does not know it, the command to turn 
from a codification to other one is iconv

Thank you Scott, now really covers me very well gpsim.

Regards

Néstor A. Marchesini
Chajari-Entre Rios-Argentina
ICQ # 50983752 colo
MSN ####@####.####
####@####.####
####@####.####
http://www.deselectronica.com.ar

Scott Dattalo escribió:
> Néstor,
> If you can send me a small program that exposes this problem, I'll try 
> it out and see if I can fix gpsim's behavior.
> Scott