[ANNOUNCE] Vala Toys for gEdit 0.4.1

3 views
Skip to first unread message

Andrea Del Signore

unread,
Feb 21, 2009, 10:46:36 AM2/21/09
to vtg...@googlegroups.com, Vala ML, gnome-ann...@gnome.org
I have to do another bug fix release since a last minute change badly
broke vtg 0.4.0, so:

Vala Toys for gEdit - "It used to deadlock"

is released. The source tarball can be downloaded here:

http://vtg.googlecode.com/files/vtg-0.4.1.tar.bz2

This version supports the new valac 0.5.7.

NEWS for version 0.4.1
======================

* Fixed a deadlock in the parser thread that causes gEdit to freeze when vtg plugin is enabled

See http://groups.google.com/group/vtg-dev/msg/c483229c6f0f3d51 the full vtg 0.4.0 announcement.


Vala Toys for gEdit
===================

Vala Toys for gEdit is an experimental collection of plugins that
extends the gEdit editor to make it a better developer editor.

Vtg tries to make less compromises as possible so, for now, its scope is
narrowed only to support the Vala programming language.

Vtg is written in Vala itself and it is currently composed of just one
plugin with four modules and it adds to gEdit:

* Bracket completion
* Symbol completion
* Project Manager
* Project build / execute

For more information see:

http://vtg.googlecode.com/

http://code.google.com/p/vtg/wiki/Documentation

http://code.google.com/p/vtg/wiki/Compile


The Vtg developer

Andrea Del Signore


luca.d...@gmail.com

unread,
Feb 21, 2009, 1:40:22 PM2/21/09
to vtg-dev
I installed vala 0.5.7 and then vtg 0.4.1 following
http://code.google.com/p/vtg/wiki/Compile

I opened Gedit, choose File->NewProject and it created a new project
for me.
If I use the terminal and call "make" on that new project, it works.
When I open the main.vala in gedit, though, it crashes as soon as I
start editing the file.

Andrea Del Signore

unread,
Feb 21, 2009, 8:14:49 PM2/21/09
to vtg...@googlegroups.com
Hi Luca,

I'm sorry but I can't reproduce this bug, can you try to execute gEdit
under gdb an get a backtrace?

I tried what you said and I can generate a new project, compile it from
vtg and edit the file without any trouble.

Thanks for testing. Cheers,
Andrea

Luca Dionisi

unread,
Feb 22, 2009, 10:32:11 AM2/22/09
to vtg...@googlegroups.com
On Sun, Feb 22, 2009 at 2:14 AM, Andrea Del Signore <sej...@tin.it> wrote:
>
> Hi Luca,
>
> I'm sorry but I can't reproduce this bug, can you try to execute gEdit
> under gdb an get a backtrace?

I'm not an expert with gdb. Is that what you want?

Reading symbols from /home/luca/.gnome2/gedit/plugins/libvtg.so...done.
Loaded symbols for /home/luca/.gnome2/gedit/plugins/libvtg.so
Reading symbols from /usr/lib/libgtksourcecompletion-1.0.so.1...done.
Loaded symbols for /usr/lib/libgtksourcecompletion-1.0.so.1
Reading symbols from /usr/lib/libglade-2.0.so.0...done.
Loaded symbols for /usr/lib/libglade-2.0.so.0
Reading symbols from /usr/lib/libvala.so.0...done.
Loaded symbols for /usr/lib/libvala.so.0
Reading symbols from /lib/libreadline.so.5...done.
Loaded symbols for /lib/libreadline.so.5
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so...done.
Loaded symbols for /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so
Reading symbols from /usr/lib/librsvg-2.so.2...done.
Loaded symbols for /usr/lib/librsvg-2.so.2
Reading symbols from /usr/lib/libgsf-1.so.114...done.
Loaded symbols for /usr/lib/libgsf-1.so.114
Reading symbols from /usr/lib/libcroco-0.6.so.3...done.
Loaded symbols for /usr/lib/libcroco-0.6.so.3
Reading symbols from /lib/libbz2.so.1.0...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /usr/lib/libtrackerclient.so.0...done.
Loaded symbols for /usr/lib/libtrackerclient.so.0
Core was generated by `gedit'.
Program terminated with signal 11, Segmentation fault.
[New process 8055]
[New process 8053]
[New process 8041]
#0 0xb61bc403 in gee_collection_get_size (self=0x0) at collection.c:79
79 return GEE_COLLECTION_GET_INTERFACE (self)->get_size (self);
(gdb) bt
#0 0xb61bc403 in gee_collection_get_size (self=0x0) at collection.c:79
#1 0xb6112380 in vala_code_context_get () at valacodecontext.c:128
#2 0xb6199186 in vala_report_error (source=0xb3a41000,
message=0xb145c88 "syntax error, expected identifier") at valareport.c:187
#3 0xb617a2f0 in vala_parser_get_error (self=0xab3a4c0,
msg=0xb61e9ce8 "expected identifier") at valaparser.c:465
#4 0xb617b577 in vala_parser_skip_identifier (self=0xab3a4c0,
error=0xb445ec98) at valaparser.c:659
#5 0xb617b881 in vala_parser_parse_identifier (self=0xab3a4c0,
error=0xb445ed08) at valaparser.c:671
#6 0xb61850d5 in vala_parser_parse_local_variable (self=0xab3a4c0,
variable_type=0xb070730, error=0xb445ed68) at valaparser.c:4155
#7 0xb6185374 in vala_parser_parse_local_variable_declarations (
self=0xab3a4c0, block=0xb3a55d20, error=0xb445eda8) at valaparser.c:4121
#8 0xb617e03c in vala_parser_parse_statements (self=0xab3a4c0,
block=0xb3a55d20, error=0xb445ee08) at valaparser.c:3734
#9 0xb617e3b5 in vala_parser_parse_block (self=0xab3a4c0, error=0xb445ee98)
at valaparser.c:4044
#10 0xb618b109 in vala_parser_parse_method_declaration (self=0xab3a4c0,
attrs=0x0, error=0xb445ef48) at valaparser.c:6696
#11 0xb618d0c2 in vala_parser_parse_declaration (self=0xab3a4c0,
error=0xb445ef88) at valaparser.c:5552
#12 0xb618ee9b in vala_parser_parse_class_member (self=0xa836108,
cl=0xb3a20458, error=0xb445eff8) at valaparser.c:6127
#13 0xb618f77b in vala_parser_parse_declarations (self=0xab3a4c0,
parent=0xb3a20458, root=0, error=0xb445f078) at valaparser.c:5668
#14 0xb619096e in vala_parser_parse_class_declaration (self=0xab3a4c0,
attrs=0x0, error=0xb445f128) at valaparser.c:6060
#15 0xb618d39c in vala_parser_parse_declaration (self=0xab3a4c0,
error=0xb445f194) at valaparser.c:5414
#16 0xb618f700 in vala_parser_parse_declarations (self=0xab3a4c0,
parent=0xb3600cb0, root=1, error=0xb445f1f8) at valaparser.c:5863
#17 0xb619048b in vala_parser_parse_file (self=0xab3a4c0,
source_file=0xb37b6b60) at valaparser.c:820
#18 0xb61906ab in vala_parser_real_visit_source_file (base=0xab3a4c0,
source_file=0xb37b6b60) at valaparser.c:407
#19 0xb6113b78 in vala_code_visitor_visit_source_file (self=0xab3a4c0,
source_file=0xb37b6b60) at valacodevisitor.c:198
#20 0xb61a671c in vala_source_file_accept (self=0xa836108, visitor=0xa836108)
at valasourcefile.c:264
#21 0xb61120ed in vala_code_context_accept (self=0xab36890, visitor=0xab3a4c0)
at valacodecontext.c:251
#22 0xb6179d61 in vala_parser_parse (self=0xab3a4c0, context=0xab36890)
at valaparser.c:391
#23 0xb62953b3 in vsc_parser_manager_parse_context (self=0xa967e90,
context=0xab36890) at vscparsermanager.c:1015
#24 0xb629749f in _vsc_parser_manager_parse_sec_contexts_gthread_func (
self=0xa967e90) at vscparsermanager.c:820
#25 0xb74e602f in ?? () from /usr/lib/libglib-2.0.so.0
#26 0xb7df250f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#27 0xb7400a0e in clone () from /lib/tls/i686/cmov/libc.so.6

Andrea Del Signore

unread,
Feb 22, 2009, 10:50:48 AM2/22/09
to vtg...@googlegroups.com
On Sun, 2009-02-22 at 16:32 +0100, Luca Dionisi wrote:
> On Sun, Feb 22, 2009 at 2:14 AM, Andrea Del Signore <sej...@tin.it> wrote:
> >
> > Hi Luca,
> >
> > I'm sorry but I can't reproduce this bug, can you try to execute gEdit
> > under gdb an get a backtrace?
>
> I'm not an expert with gdb. Is that what you want?

Hi Luca,

yes this is exactly what I want thanks. From this part of the backtrace:

> #0 0xb61bc403 in gee_collection_get_size (self=0x0) at collection.c:79
> 79 return GEE_COLLECTION_GET_INTERFACE (self)->get_size (self);
> (gdb) bt
> #0 0xb61bc403 in gee_collection_get_size (self=0x0) at collection.c:79
> #1 0xb6112380 in vala_code_context_get () at valacodecontext.c:128
> #2 0xb6199186 in vala_report_error (source=0xb3a41000,
> message=0xb145c88 "syntax error, expected identifier") at valareport.c:187
> #3 0xb617a2f0 in vala_parser_get_error (self=0xab3a4c0,
>

I suspect that you are using vtg < 0.4.0 with vala 0.5.7, can you double
check if you have another copy of libvtg.so around?

To be sure delete all the libvtg.so libraries that you have in your
system and reinstall the one compiled with the vtg 0.4.1 tarball.

Hope this helps. Cheers,
Andrea


Luca Dionisi

unread,
Feb 22, 2009, 11:31:49 AM2/22/09
to vtg...@googlegroups.com
On Sun, Feb 22, 2009 at 4:50 PM, Andrea Del Signore <sej...@tin.it> wrote:
> I suspect that you are using vtg < 0.4.0 with vala 0.5.7, can you double
> check if you have another copy of libvtg.so around?
>
> To be sure delete all the libvtg.so libraries that you have in your
> system and reinstall the one compiled with the vtg 0.4.1 tarball.
>

Yes, you were right.

I removed the directory ~/.gnome2/gedit/plugins/*
after checking that all in there was from vtg package.

Then I rebuilt the vtg and did "sudo make install"
It copied many things in ~/.gnome2/gedit/plugins but
I had to do manually these 2 lines from the instructions in the wiki:
cp vtg/vtg.gedit-plugin ~/.gnome2/gedit/plugins/
cp vtg/.libs/libvtg.so ~/.gnome2/gedit/plugins/

Then the plugin was there in gedit, and it doesnt crash when I edit the file.

Thanks and keep up the good work.

Michel S.

unread,
Feb 24, 2009, 10:36:07 PM2/24/09
to vtg-dev
Hi Andrea,

On Feb 21, 10:46 am, Andrea Del Signore <seje...@tin.it> wrote:
> I have to do another bug fix release since a last minute change badly
> broke vtg 0.4.0, so:
>
> Vala Toys for gEdit - "It used to deadlock"
>
> is released. The source tarball can be downloaded here:
>
> http://vtg.googlecode.com/files/vtg-0.4.1.tar.bz2
>
> This version supports the new valac 0.5.7.
>
vtg has recently been packaged for Fedora, and I'm currently testing
0.4.1 to ship as an update (we call it gedit-vala).

One question: when doing "Execute", it looks like I have to enter the
relative path to the binary (e.g. src/ProjectName), otherwise vtg will
try launching /path/to/ProjectName instead. Is this intentional? If
the project is generated by vala-gen-project, surely the path to the
binary can be picked up automatically.

I just realized that installing vtg should probably bring in the
autotools suite, as well as vala and gtk2-devel, otherwise the sample
application would not work out of the box too. Will issue a fix once
we have the Execute thing clarified.

Thanks,

--
Michel Salim

Andrea Del Signore

unread,
Feb 25, 2009, 8:10:23 AM2/25/09
to vtg...@googlegroups.com
On Tue, 2009-02-24 at 19:36 -0800, Michel S. wrote:
> Hi Andrea,

Hi Michel,

>
> >
> vtg has recently been packaged for Fedora, and I'm currently testing
> 0.4.1 to ship as an update (we call it gedit-vala).

that's good! gedit-vala I like the name too.

>
> One question: when doing "Execute", it looks like I have to enter the
> relative path to the binary (e.g. src/ProjectName), otherwise vtg will
> try launching /path/to/ProjectName instead. Is this intentional? If
> the project is generated by vala-gen-project, surely the path to the
> binary can be picked up automatically.

Yes you have to specify a relative (to the project root) path when using
the command line, but I think that that can be changed if is adds more
flexibility.

On another side I just verified that to porting from gnome-build to
libvbf broke the list in the execute dialog, since that list should be
filled with the executable(s) built in the project, so using the command
line entry can be avoided most of the time.

I'll fix that in the next release.

>
> I just realized that installing vtg should probably bring in the
> autotools suite, as well as vala and gtk2-devel, otherwise the sample
> application would not work out of the box too. Will issue a fix once
> we have the Execute thing clarified.
>
> Thanks,

I hope this help. Regards,
Andrea
>
> --
> Michel Salim
>
> >

Reply all
Reply to author
Forward
0 new messages