[Factor-talk] Metadata
Hi, all-- I'm wondering what the Factor community would think of including certain kinds of metadata in the source code for vocabularies and for the Factor itself. My starting point for this line of thinking was that I had played with Factor for a while a couple of years ago, then dropped it for a while ... and I wanted to know what version I had installed. So my first thought was to go to the listener and try version Nope. Okay, how about factor-version ? No again. And so on through several variations ... nothing. Nor could I find anything in the online help. Nor any file in the source directory to indicate the version (or revision date). And it occurs to now, which should be obvious, that I can probably use Git to find out some pertinent info. However: * Not everyone is using Git. * Version info is useful, not just for the purpose I mentioned, but also for debugging. * It seems desirable to be able to query version info via the listener, and probably also programatically for the purpose of checking dependencies among vocabularies. Furthermore, there is probably other metadata that would be a good idea to maintain. For example, if Factor becomes widely used, there might be a situation where different developers distribute similarly- or identically-named vocabularies. So we should have the developer's name, or email address, or some other identifier that serves to distinguish a given vocabulary from a different one with the same name. Personally, I feel pretty strongly about this; if I were in charge of development I would make at least the above-mentioned items *mandatory* for all language components, such that a vocabulary would fail to load or compile if it didn't include the required metadata. But I think I've said enough. I will leave it up to more experienced folks to decide whether and how to implement this idea. Thanks for reading! -- Matt Gushee m...@gushee.net -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor GUI fails w/ cairo error
Hi Matt, On Sat, Aug 27, 2011 at 12:00 PM, Matt Gushee m...@gushee.net wrote: A couple of details that could be important: my desktop computer is rather [ahem] embarrassingly old ... so it doesn't have SSE2. Therefore I can't use a prebuilt package. I built factor last Sunday using the ./build-support/factor.sh update command. This was newly created directory, to insure that there would be no troublesome files hanging around from my previous installation. I also rebuilt factor last night, but it did not make any difference. There is a known bug in the Factor compiler where it generates invalid code if SSE2 is not available. I created an issue for it: https://github.com/slavapestov/factor/issues/56 In other news, we now have an issue tracker. So I've been busy with a new job for the last year so I haven't had much time to work on Factor, but I'm trying to make time here and there to fix bugs. I'll definitely prioritize this one now that I see there are still people with pre-SSE computers :-) Slava -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Metadata
On Aug 27, 2011, at 12:32 PM, Matt Gushee wrote: * Version info is useful, not just for the purpose I mentioned, but also for debugging. I agree that there ought to be a user-readable version number available programmatically. There is a build number in the image (accessible by USE: kernel build) that can be correlated to the build farm's nightly builds, but it's not humanly relatable to a git revision or version number, which sucks. Furthermore, there is probably other metadata that would be a good idea to maintain. For example, if Factor becomes widely used, there might be a situation where different developers distribute similarly- or identically-named vocabularies. So we should have the developer's name, or email address, or some other identifier that serves to distinguish a given vocabulary from a different one with the same name. Factor vocabularies can already store author information and other metadata; however, I don't know that those are good axes for vocab differentiation. Vocabs are canonically objects in Factor, and their names are just used as assoc indexes by the standard loader; someone could construct their own vocab loader that used, say, a git URL/refid/path triple as the vocab key. What if you could say something like: FROM-GIT: https://github.com/cptahab/pequod.git 1a2b3c4e starbuck ishmael queequeg ; FROM-GIT: https://savannah.gnu.org/adama/galactica.git 5f607182 starbuck ; ! this is a different starbuck vocab from the previous to download a particular version of a repo and import vocabs from it, not worrying about clashing with other repos? -Joe smime.p7s Description: S/MIME cryptographic signature -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Metadata
I don't think versioning the vocabularies included in Factor is necessary. You don't see versions in standard libraries of other languages. However, it would be nice if released versions of Factor reported their version numbers properly. On Aug 27, 2011, at 12:32 PM, Matt Gushee m...@gushee.net wrote: Hi, all-- I'm wondering what the Factor community would think of including certain kinds of metadata in the source code for vocabularies and for the Factor itself. My starting point for this line of thinking was that I had played with Factor for a while a couple of years ago, then dropped it for a while ... and I wanted to know what version I had installed. So my first thought was to go to the listener and try version Nope. Okay, how about factor-version ? No again. And so on through several variations ... nothing. Nor could I find anything in the online help. Nor any file in the source directory to indicate the version (or revision date). And it occurs to now, which should be obvious, that I can probably use Git to find out some pertinent info. However: * Not everyone is using Git. * Version info is useful, not just for the purpose I mentioned, but also for debugging. * It seems desirable to be able to query version info via the listener, and probably also programatically for the purpose of checking dependencies among vocabularies. Furthermore, there is probably other metadata that would be a good idea to maintain. For example, if Factor becomes widely used, there might be a situation where different developers distribute similarly- or identically-named vocabularies. So we should have the developer's name, or email address, or some other identifier that serves to distinguish a given vocabulary from a different one with the same name. Personally, I feel pretty strongly about this; if I were in charge of development I would make at least the above-mentioned items *mandatory* for all language components, such that a vocabulary would fail to load or compile if it didn't include the required metadata. But I think I've said enough. I will leave it up to more experienced folks to decide whether and how to implement this idea. Thanks for reading! -- Matt Gushee m...@gushee.net -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Merged native-image-loader branch
I updated and merged my old native-image-loader branch, which makes Factor use the native Cocoa/Win32 facilities for loading images, along with Philipp Brueschweiler's gtk-image-loader branch that adds the same functionality for the GTK backend. I've tested that Windows and OS X work; could somebody test the GTK code? I've committed my merge to git:// github.com/jckarter/factor.git, branch merge-native-image-loader. -Joe -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Metadata
On Aug 27, 2011, at 2:36 PM, John Benediktsson wrote: I don't think versioning the vocabularies included in Factor is necessary. You don't see versions in standard libraries of other languages. Sure, but some sane and convenient mechanism for loading and versioning third-party modules is pretty much a must-have these days. -Joe smime.p7s Description: S/MIME cryptographic signature -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Merged native-image-loader branch
Hi Joe,
On Sat, Aug 27, 2011 at 4:05 PM, Joe Groff arc...@gmail.com wrote:
I updated and merged my old native-image-loader branch, which makes Factor
use the native Cocoa/Win32 facilities for loading images, along with Philipp
Brueschweiler's gtk-image-loader branch that adds the same functionality for
the GTK backend. I've tested that Windows and OS X work; could somebody test
the GTK code? I've committed my merge
to git://github.com/jckarter/factor.git, branch merge-native-image-loader.
Looks good to me.
Maybe move images.{jpeg,png,gif,tiff} to extra/ then?
Slava
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Merged native-image-loader branch
On Aug 27, 2011, at 5:15 PM, Slava Pestov wrote: Hi Joe, I saw you merged your changes. However bootstrap fails on Linux now: I thought you said you tested them... Regardless, I also went ahead and moved the pure Factor image libraries to extra/ as you suggested. -Joe smime.p7s Description: S/MIME cryptographic signature -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Merged native-image-loader branch
I'm not sure how to fix the gtk problem. It looks like there was a bad merge. For example, now both glib.ffi and gobject-introspection.standard-types define the guint8, etc types. Are Anton or Philipp still around? On Sat, Aug 27, 2011 at 5:32 PM, Joe Groff arc...@gmail.com wrote: On Aug 27, 2011, at 5:15 PM, Slava Pestov wrote: Hi Joe, I saw you merged your changes. However bootstrap fails on Linux now: I thought you said you tested them... Regardless, I also went ahead and moved the pure Factor image libraries to extra/ as you suggested. -Joe -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] native-image-loader load error
Hi Anton, Joe merged Blei's native-image-loader work, unfortunately the gtk UI backend doesn't bootstrap anymore and I can't figure out the problem. Do you think you'll find some time to take a look at it? It looks like glib.ffi and gobject.ffi both define GError now, and glib.ffi and gobject-introspection.standard-types define the same set of types. Which one is the definitive one? Should we scrap the code in glib.ffi? If so, GErrorg-error and handle-GError will need to go somewhere else. Thanks, Slava -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Merged native-image-loader branch
Hi all!
I'll take a look at these errors soon (not today, but soon).
About gdk_pixbuf_get_pixels: it seems that definition of this function
is incorrect (in GdkPixbuf-2.0.gir). Maybe it's already fixed in the
latest version.
2011/8/28 Slava Pestov sl...@factorcode.org:
Hi Joe,
Thanks for taking a look at this.
On Sat, Aug 27, 2011 at 6:03 PM, Joe Groff arc...@gmail.com wrote:
It looks like the glib.ffi version got factored out after Blei originally
branched, but the merge threw it all back in again. I pushed a patch that
merges the actual changes in by hand. Does it get further now?
There's one remaining load error; GError' s definition is duplicated.
In glib.ffi, it's a struct, in gobject.ffi it's a opaque C-TYPE. This
suggests the latter is erronous:
resource:basis/gdk/pixbuf/ffi/ffi.factor
27: f { { pointer: GError initial: f } }
^
More than one vocabulary defines a word named “GError”
The following restarts are available:
:1 Use the glib.ffi vocabulary
:2 Use the gobject.ffi vocabulary
:3 Load resource:basis/gdk/pixbuf/ffi/ffi.factor again
4 :res Load resource:basis/gdk/ffi/ffi.factor again
5 :res Load resource:basis/ui/backend/gtk/gtk.factor again
When I try to run it, I get this error:
( scratchpad ) ui.tools run
Generic word underlying does not define a method for the fixnum class.
Dispatching on object: 192
Type :help for debugging help.
( scratchpad ) :c
(U) Quotation: [ c-to-factor - ]
Word: c-to-factor
(U) Quotation: [ swap c call - c drop ]
(O) Word: command-line-startup
(O) Word: listener
(O) Word: (listener)
(U) Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U) Quotation: [ call - datastack ]
(O) Method: M\ gtk-ui-backend (with-ui)
(O) Word: start-ui
(U) Quotation: [ listener-window* - drop ]
(O) Word: listener-window*
(O) Word: listener-gadget
(O) Word: add-toolbar
(O) Word: toolbar
(O) Word: command-button
(O) Word: border-button
(O) Method: M\ button-pen pen-pref-dim
(O) Method: M\ tile-pen pen-pref-dim
(O) Word: image-dim
(O) Word: cached-image
(O) Method: M\ gtk-image streamimage
(O) Word: GdkPixbufimage
(O) Word: memorybyte-array
(O) Method: M\ object underlying
(O) Word: no-method
(O) Method: M\ object throw
(U) Quotation: [
63 special-object error-thread set-global
continuation - error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Looks like the ffi definition for gdk_pixbuf_get_pixels is wrong; look
at the return type:
USING: alien.syntax gobject-introspection.standard-types ;
IN: gdk.pixbuf.ffi
LIBRARY: gdk.pixbuf FUNCTION: guint8 gdk_pixbuf_get_pixels
( GdkPixbuf* pixbuf ) ; inline
Slava
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
