Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)
On 20 January 2012 03:37, Jimmie Houchin jlhouc...@gmail.com wrote: On 1/17/2012 2:57 PM, Frank Shearar wrote: Emacs + SLIME = image-based, interactive development. As image-based as you'd like, at least. Eclipse + Cusp = image-based development: you're connecting to a running Common Lisp image, which you can snapshot and restore any time you like (just like choosing to work in a built image or in a persistent one). IDE and living world are orthogonal concerns. Ok. I have no experience in this realm. It may be exactly as you say. But within the context of this discussion and this discussion occurring in a Smalltalk forum I want to bring up a common Smalltalk experience. One thing that I dearly love in my Pharo environment is this. I have multiple browser windows open with code I am viewing or editing. I have one or more workspaces open with code and objects that I am experimenting with or exploring their values to learn. I save my image, and open back up and all of that is there ready for me to continue. I can do this with the image on a flash drive, the local drive or on a network. With this Emacs + SLIME can I do some thing similar? Honest question, honest comparison? I suspect the answer, but I do not factually know it. When I restore an Emacs+SLIME image. Do I have available the editing and the REPL (or workspace like element) exactly as I left it. Cursors in the original location. Workspace like elements with the objects available for exploration. If as I suspect the answer is no. Then we are not exactly talking about the same things. Maybe similar or close, but not the same. However, I am happy to agree that LISPs are worlds ahead of most other languages in this regard. If one's using Emacs + SLIME, one of course doesn't have any Browsers or Workspaces or indeed any UI elements, so in a sense, no, we're not comparing the same things. If you saved your image, the image state would remain - running processes and so on - but of course Emacs's state - windows open and the like - would vanish. I won't dispute the value of the strong integration between IDE and environment. I certainly think it's perfectly sane for you to value it so highly! What I find inconvenient about the current work is * I have to manage windows manually * I can see only a single method at a time, so can't use visual cues or keyboard-only navigation to jump around It's not even impossible to do the above in Pharo. Laurent's already working on the first step, and the old Whisker Browser could display many methods at once. The reasons why I want something like Emacs + SLIME for Smalltalk are * Emacs is very good at handling text, and I wouldn't have to learn yet another editor's bindings. (I've already paid this price, but I'm thinking of new people.) * It's much easier on the network to connect my Emacs to a remote running image than having to VNC to something. Plus it's one less application open. * I don't want the Smalltalk community to waste its precious resources reinventing tools that are perfectly good out of some notion that Smalltalk is a unique, special snowflake, and we simply cannot make use of standard tools. For me this is one simple value of the IDE in the image and being one of the many live objects I am editing. One of the things that was seen as having no value in this discussion. I see working in the image as both a blessing and a curse: it's a blessing because you can work rapidly and interact with your objects. It's a curse because there's nothing stopping you from making something that cannot be replicated/reproduced. In the large, writing Metacello specs and running them in a CI environment will tend to keep you honest. frank And as I stated, if the proposer sees no value in this. Fine, do what works for you. Jimmie
[Pharo-project] Which COG VM?
The latest COG VM, pointed to from the Pharo-project download page, CogVM-*-13307.zip, seems to be a little unstable. Many students have been reporting that it just hangs while doing nothing more than editing (not saving) text, and I have seen long hangs while doing trivial things — these look to me like synchronization bugs. The COG that I used about a year ago (Jann–March 2011 timeframe), in contrast, seemed rock solid, although it might have been slower. I have two questions. First, where can I find an archive of PRE_BUILT VMs. I don't want to give my students (or myself) the task of building a VM from scratch. Second, how can I find out what version of COG I'm running? SmalltalkImage current versionLabel doesn't work. SmalltalkImage current buildDate gives me a date, but how does that relate to the version numbers that I see in on the COG web site? Thanks. I want my students to have a good starting experience with Pharo, and they are not. They are messing around trying to retrieve source from hosed images :-( Andrew
Re: [Pharo-project] Which COG VM?
try Smalltalk vm version On Fri, Jan 20, 2012 at 12:16 PM, Andrew P. Black bl...@cs.pdx.edu wrote: Second, how can I find out what version of COG I'm running? Andrew
Re: [Pharo-project] Best way for FFI in Pharo
So, am I getting this right: if I need callbacks, then I need NativeBoost? Can those callbacks be used in situations where it is necessary to deliver very high number of them quickly and efficiently? I am looking at libev - event library used to deliver high I/O traffic through evented interface, and it depends heavily on callbacks to deliver each event. Are there prebuilt VM-s with NB? - http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4313534.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Best way for FFI in Pharo
see https://ci.lille.inria.fr/pharo/view/NativeBoost/ On Fri, Jan 20, 2012 at 12:31 PM, drush66 davorin.rusevl...@gmail.comwrote: Are there prebuilt VM-s with NB? - http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4313534.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] Which COG VM?
Unfortunately the VM from the one click package has a bug when it comes to FFI. You can download latest Cog from Eliots archive: http://www.mirandabanda.org/files/Cog/VM/?C=M;O=D No need to compile here. I use them too. Note that Eliots one (with source managed in subversion) is not the official pharo VM, but the official CogVM for Squeak and Pharo. Pharo has its own fork and which is github managed. From time to time Igor moves fixes from Eliots CogVM into the Pharo Cog VM. At least thats how I understood it ... Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: [Pharo-project] Which COG VM?
Perhaps you can try using squeakvm as VM. I had several problems with Cog (on my linux), but squeakvm runs without problem. I don't want to judge, but I think that Cog is pretty much faster, but squeakvm is solid. Jan
[Pharo-project] speeding up copying World using dirty rectangles?
in my Gui to OpenGL code, I'm doing a very naive procedure to copy the World to an OpenGL at every #step. I know that there's many ways to speed this up (I get only 10fps with a saturated core when I do it the simplest way). Suggestsion on how to make the following more efficient? THanks. getLatestImageFromWorld |format form tempTextures| pasteUpFormCanvas ifNil: [^self]. self hide. myPasteUp fullDrawOn: pasteUpFormCanvas. self show. form := pasteUpFormCanvas form. fPUWidth := form width. fPUHeight := form height. tempTextures := WordArray with: (textureIntNames at: 1). ogl glDeleteTextures: 1 with: tempTextures. ogl glBindTexture: GLTexture2d with: (textureIntNames at: 1). ogl checkForError. format := ogl textureInternalFormat. ogl glEnable: GLTexture2d. ogl glTexParameteri: GLTexture2d with: GLTextureMinFilter with: GLLinear. ogl glTexParameteri: GLTexture2d with: GLTextureMagFilter with: GLLinear. ogl glTexImage2D: GLTexture2d with: 0 with: format with: form width with: form height with: 0 with: ogl texturePixelFormat with: ogl texturePixelType with: form bits.
[Pharo-project] ANN: OpenGL + NativeBoost + Mac == success
Today i'm happy to announce that i can run my 2 years-old demo which i did when created NBOpenGL bindings first on Windows, working without ANY changes in code on Mac. The main hurdle with adding MacOsx support was that it is largely unknown platform to me , and there are 3 different ways to get there, namely CGL, Carbon and Cocoa. Fortunately CGL approach worked well, despite its a bit limited (you cannot create a windowed context, only fullscreen or offscreen one). But since i am using FBO's , it doesn't really matters. Of course it may make difference for people who want to use GL in different setup. In order to load project, take a fresh Pharo 1.4 image, load ConfigurationOfNBOpenGL package using MC from MCHttpRepository location: 'http://www.squeaksource.com/NBOpenGL' user: 'sig' password: '' or by Gofer it squeaksource: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load and then issue: ConfigurationOfNBOpenGL project lastVersion load. Remember, that you have to use CogVM with NativeBoost plugin, which you can download from here: https://ci.lille.inria.fr/pharo/view/NativeBoost/job/NB-Cog-Mac-Carbon/lastSuccessfulBuild/artifact/ If everything goes well, you should be able to run a demo by doing: GLTTRenderingDemo new openInWorld. P.S. @ Windows users: due to refactorings which i did, a windows-specific support code is currently broken. So please use older versions of packages (prior to this month). I will fix them very soon. -- Best regards, Igor Stasenko.
Re: [Pharo-project] [squeak-dev] Re: Saga of trying to integrate IDE with OpenGL continuesRe:
On 20 January 2012 01:29, Lawson English lengli...@cox.net wrote: Apparently there was a glError that I wasn't catching, so the disk address issue has gone away: the Baloon3D plugin was logging errors I didn't catch. However, I'm not sure how to efficiently blit GUI updates to the gl texture, so suggestions appreciated. Looking at the Squeak3D.log file, it seems to me that Baloon3D already has access to all the values that Igor is using to setup his NBOpenGL and GLCanvas packages. Would it be better to leverage that as a cross-platform initialization for OpenGL instead of another plugin? My point is following: the more logic you put into VM code (plugin etc), the more limited you are. Because instead of deciding by yourself, what you prefer and what not, someone else deciding for you. I hate constraints, especially in such performance sensitive areas as graphics, where changing a single flag value could mean 10x difference in performance (if not 100x). If we ever need some helpers from VM side is mainly glue code to obtain some handles to resources (like main window handle, etc). But all levers of controls should be at language side, VM should serve as a dummy servant who has no idea what you going to do and just strictly following your orders. From Squeak3D log: ### Attempting to find hardware renderer x: 0 y: 0 w: 638 h: 475 Selected pixel format: AGL_RENDERER_ID : 0x1021A02 AGL_OFFSCREEN : GL_FALSE AGL_FULLSCREEN : GL_FALSE AGL_WINDOW : GL_TRUE AGL_ACCELERATED : GL_TRUE AGL_ROBUST : GL_FALSE AGL_BACKING_STORE : GL_FALSE AGL_MP_SAFE : GL_TRUE AGL_COMPLIANT : GL_TRUE AGL_MULTISCREEN : GL_TRUE AGL_BUFFER_SIZE : 32 AGL_LEVEL : 0 AGL_PIXEL_SIZE : 32 AGL_DEPTH_SIZE : 24 AGL_STENCIL_SIZE : 8 AGL_3_BIT AGL_AUX_BUFFERS : 0 OpenGL vendor: ATI Technologies Inc. OpenGL renderer: ATI Radeon HD 2600 OpenGL Engine OpenGL version: 2.1 ATI-1.6.36 OpenGL extensions: GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_vertex_blend GL_ARB_window_pos GL_ARB_shader_objects GL_ARB_vertex_shader GL_ARB_shading_language_100 GL_EXT_multi_draw_arrays GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_geometry_shader4 GL_EXT_transform_feedback GL_APPLE_client_storage GL_APPLE_specular_vector GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators GL_APPLE_element_array GL_APPLE_flush_render GL_APPLE_aux_depth_stencil GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip GL_SGIS_generate_mipmap GL_ARB_imaging GL_ARB_point_parameters GL_ARB_texture_env_crossbar GL_ARB_texture_border_clamp GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_texture_cube_map GL_ARB_texture_env_dot3 GL_ARB_multisample GL_ARB_texture_env_combine GL_ARB_texture_compression GL_ARB_texture_mirrored_repeat GL_ARB_shadow GL_ARB_depth_texture GL_ARB_shadow_ambient GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_occlusion_query GL_ARB_point_sprite GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ARB_pixel_buffer_object GL_ARB_draw_buffers GL_ARB_shader_texture_lod GL_ARB_color_buffer_float GL_ARB_half_float_vertex GL_ARB_texture_rg GL_ARB_texture_compression_rgtc GL_ARB_framebuffer_object GL_EXT_compiled_vertex_array GL_EXT_draw_buffers2 GL_EXT_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_texture_rectangle GL_ARB_texture_rectangle GL_EXT_texture_env_add GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_texture_lod_bias GL_EXT_abgr GL_EXT_bgra GL_EXT_stencil_wrap GL_EXT_texture_filter_anisotropic GL_EXT_separate_specular_color GL_EXT_secondary_color GL_EXT_blend_func_separate GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_sRGB GL_EXT_blend_equation_separate GL_EXT_texture_mirror_clamp GL_EXT_packed_depth_stencil GL_EXT_bindable_uniform GL_EXT_texture_integer GL_EXT_gpu_shader4 GL_EXT_framebuffer_sRGB GL_EXT_provoking_vertex GL_APPLE_flush_buffer_range GL_APPLE_ycbcr_422 GL_APPLE_rgb_422 GL_APPLE_vertex_array_range GL_APPLE_texture_range GL_APPLE_float_pixels GL_ATI_texture_float GL_ARB_texture_float GL_ARB_half_float_pixel GL_APPLE_pixel_buffer GL_APPLE_object_purgeable GL_NV_blend_square GL_NV_fog_distance GL_NV_conditional_render GL_ATI_texture_mirror_once GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_texture_env_combine3 GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGI_color_matrix GL_EXT_texture_array GL_EXT_vertex_array_bgra
Re: [Pharo-project] Best way for FFI in Pharo
Thanks, a lot for your first-hand experience. On 8 January 2012 20:29, ncalexan ncalexan...@gmail.com wrote: fstephany wrote I'm also a bit lost between all the different options (plugins, NativeBoost, FFI, Alien). I also found this confusing, so let me tell my recent experience and my conclusion. I have written bindings to the SDL game programming library for use with Pharo. SDL is cross-platform, and I want to support Mac (most of all), Windows (one must), and Linux (if I must). As far as I can tell, Alien is not cross-platform and not maintained, so I have not spent time investigating it. Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package which parses the relevant C header files and then writes either an NB or FFI callout class tree. I need to define a few structures, make a class pool with some constants, and then define lots of callouts, many of which take references to structures (like 'foo(struct x*)'). Do you have it available somewhere? I was able to make both work, more or less, on my Macbook Pro, using stock Pharo 1.3 images and Igor's NBCog.app. I found NB to be a nicer programmer experience but I found that the FFI just works. There are a lot of gratuitous differences, but: * NB requires a VM compiled with a separate plugin (that I built from source with no trouble -- Igor has done splendid work with CMakeVMMaker). * NB should be faster than the FFI at pretty much everything, but I can't say since I haven't measured. * NB has useful primitives for determining if your external objects are still valid and for determining the current operating system (I intend to use these even if I don't use NB). * NB has very few tests and examples and essentially no documentation. :) Yes, i should start writing it. I was waiting till project will mature enough stabilize a bit. and of course i am lazy. * NB has a simple conceptual model, but it is still not as simple as the FFI model. yep. a bit more concepts, because a bit more features. * NB uses variableByteClasses to great advantage -- this is very cool. * NB makes it easy to crash your image, since you are evaluating native code in image. this statement can be applied to any FFInterface, if you declare function with wrong types/arguments or pass wrong argument values. :) I spent last 3 days rewriting aligment interface, and hacking opengl glue code, and guess what: it never crashed on me. And yes, i saving image every time before going to run the freshly hacked assembly code :) * NB is still, to my eye, raw and untested on Mac. I had problems with stack alignments in bizarre places, and NB's interaction with garbage collection basically ended my attempts to use it. need more data, data pls. I refined a stack-aligned interface recently, and don't have any problems with alignment.. but sure, i maybe lack of real-world experience ;) * NB is basically impossible to debug if you aren't very strong with x86 assembly (I'm not even strong with x86 assembly), and the stack manipulations rendered GDB pretty much useless for me. well, you don't have to go there. Usually i takes less time to grok assembler code in image to find an error than trying to understand what happens in GDB.. in text mode... ohh :) * NB does not integrate well with the Pharo tools -- I think the MethodTrailers are screwing up references, implementors, and source views, but I haven't investigated. Hmm.. there should be everything fine there. Trailers are not stripping any interpreter-specific state, just adds own on top of it. * NB does not seem to support indirections very easily -- I struggled to understand how to interface to foreign C functions with specs like 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually gave up. consider following: struct x k; struct x * l = k; struct x ** m = l; struct x foo (k);push k, because all structs are passed by reference. struct x * foo (l); push value of l = k struct x ** foo (m); push value of m = l l obviously k becasue k points to first byte of your structure, while l points to first byte of _pointer_ to that structure. usually a ** used in cases when function wants to store result on success. It is like say: give me a memory location where i should store a pointer to that structure, so you can use it later. Unfortunately there is no way to automate that. It means that if you owning a structure, myStruct = NBExternalStructureSubclass new. passing it as argument to functions which takes struct x** may be dangerous. So, in case if function under the question wants to return a pointer to struct back to you, you can do just following: - change the function declaration to following: #( void foo ( NBExternalAddress * address ) ) this stands for void foo(struct **x) in this case NB will not push the value of address , but a place in memory where this pointer is stored. Function then writes a new address value
