Vm-dev December 2010

vm-dev@lists.squeakfoundation.org

42 participants
109 discussions

Re: [Vm-dev] xcode and VM plugins
by Igor Stasenko 19 Dec '10

19 Dec '10

On 19 December 2010 18:01, Ken G. Brown <kbrown(a)mac.com> wrote: > > Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. > Thanks, captain obvious :) Now tell me how i call force xcode to automatically do not include some/all .c files into build, based on the contents of plugins.int file ? :) > Ken > > At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >> >>Hello, >> >>i just wonder, how one could force xcode to compile & link only those >>internal plugins, which is listed in >>plugins.int? >> >>This is sorta easy to do using makefiles.. but with xcode.. im lost.. >> >>Any ideas? >> >>-- >>Best regards, >>Igor Stasenko AKA sig. > > -- Best regards, Igor Stasenko AKA sig.

7 15

Re: [Pharo-project] Issue 3446 in pharo: VMMakerTool load config buttondoesn't work
by Levente Uzonyi 19 Dec '10

19 Dec '10

On Fri, 17 Dec 2010, Javier Pimás wrote: > OK, if I'm correct the 3449 issue is fixed and integrated now. So how do we > solve this one? Because the method lays on VMMakerTool's code, for squeak. > Maybe we can add a line to ConfigurationOfVMMaker>>#fixVMMakerForPharo like > this: > > (Smalltalk at: #VMMakerTool) compile: > 'loadConfig > | fileResult file | > fileResult := UIManager default chooseFileMatching: #(''*.config'') label: > ''Select > VMMaker configuration...''. > fileResult > ifNotNil: [file := fileResult. > [vmMaker := VMMaker forConfigurationFile: file. > vmMaker logger: logger. > vmMaker platformDirectory] > on: Error > do: [self inform: ''Possible problem with path settings or platform > name?'']. > self updateAllViews]' > > > It's a bit of a dirty hack, maybe there's a cleaner way. What do you think? No need to do dirty hacks, just communicate your needs properly. Ask David to update the method. Squeak (since 3.9) also implements UIManager >> #chooseFileMatching:label:. Note that the name of this method is a bit misleading. The first argument is a list of "file extensions", not a list of patterns. So this should work in both Squeak and Pharo: fileResult := UIManager default chooseFileMatching: #('config') label: 'Select VMMaker configuration...'. Since fileResult is a string that contains the full path, the variable "file" is not necessary anymore. Levente > > Regards, > Javier. > > On Fri, Dec 17, 2010 at 8:35 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > >> It seems the implementation in MorphicUIManager uses the patterns >> as extensions. >> >> So >> fileResult := UIManager default chooseFileMatching: #('config') label: >> 'Select >> VMMaker configuration...'. >> >> would work. >> >> However, that misses the meaning of patterns. >> I've raised issue http://code.google.com/p/pharo/issues/detail?id=3449with change set attached... >> >> Regards, Gary >> >> ----- Original Message ----- From: <pharo(a)googlecode.com> >> To: <pharo-project(a)lists.gforge.inria.fr> >> Sent: Friday, December 17, 2010 4:21 AM >> Subject: [Pharo-project] Issue 3446 in pharo: VMMakerTool load config >> buttondoesn't work >> >> >> >> Status: New >>> Owner: ---- >>> >>> New issue 3446 by elpochodelagente: VMMakerTool load config button doesn't >>> work >>> http://code.google.com/p/pharo/issues/detail?id=3446 >>> >>> Pharo image: dev 1.1.1 >>> Pharo core version: Pharo-1.1-11411 >>> Virtual machine used: custom linux, allmost latest VMMaker, classic (not >>> cog) >>> Class browser used if applicable: OBSystemBrowserAdaptor >>> >>> Steps to reproduce: >>> 1. Load VMMaker with >>> 2. Open the VMMakerTool with: "VMMakerTool openInWorld" >>> 3. Push load config button, you get an error message >>> >>> The problem is that VMMaker tool makes use of StandardFileDialog, which >>> isn't present in Pharo anymore. The method that raises the error is >>> >>> VMMakerTool>>#loadConfig >>> | fileResult file | >>> fileResult := (StandardFileMenu oldFileMenu: FileDirectory default >>> withPattern: '*.config') startUpWithCaption: 'Select VMMaker >>> configuration...'. >>> fileResult >>> ifNotNil: [ >>> file := fileResult directory fullNameFor: fileResult name. >>> [ >>> vmMaker := VMMaker forConfigurationFile: file. >>> vmMaker logger: logger. >>> vmMaker platformDirectory >>> ] >>> on: Error >>> do: [self inform: 'Possible problem with path settings or >>> platform name?']. >>> self updateAllViews] >>> >>> >>> Changing >>> >>> fileResult := (StandardFileMenu oldFileMenu: FileDirectory default >>> withPattern: '*.config') startUpWithCaption: 'Select VMMaker >>> configuration...'. >>> >>> for >>> >>> fileResult := UIManager default chooseFileMatching: nil label: 'Select >>> VMMaker configuration...'. >>> >>> and >>> >>> file := fileResult directory fullNameFor: fileResult name. >>> >>> for >>> >>> file := fileResult >>> >>> Fixes it almost completely. It would be better to use chooseFileMatching: >>> #('*.config') but it didn't work well. >>> >>> >>> >>> >> >> > > > -- > Javier Pimás > Ciudad de Buenos Aires >

3 5

xcode and VM plugins
by Igor Stasenko 19 Dec '10

19 Dec '10

Hello, i just wonder, how one could force xcode to compile & link only those internal plugins, which is listed in plugins.int? This is sorta easy to do using makefiles.. but with xcode.. im lost.. Any ideas? -- Best regards, Igor Stasenko AKA sig.

2 1

VM Maker: VMMaker-dtl.211.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 17 Dec '10

17 Dec '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.211.mcz ==================== Summary ==================== Name: VMMaker-dtl.211 Author: dtl Time: 17 December 2010, 3:01:45 am UUID: 6d71ce58-6e8e-428b-960b-33d90da97441 Ancestors: VMMaker-dtl.210 VMMaker 4.4.2 Use UIManager instead of StandardFileMenu for loading and saving configuration files (for Squeak/Pharo portability). Also remember last config file used, use this as default and fix path if needed after copying image to a different platform. Adopt #lookupMethodInDictionary: from oscog, adds an #isOopCompiledMethod: check.

1 0

Is there a way to compile StackVM from XCode?
by Mariano Martinez Peck 17 Dec '10

17 Dec '10

Hi eliot. I am using CoreVM.xcodeproj to compile a CogVM. I have integrated several of my own changes that I used to have in standard vm into cog...As expected, I have several errors/crash and so I thought that a first step would be to make it work with StackVM and then in Cog... So, I want to compile and debug the StackVM using XCode. I tried using the CoreVM.xcodeproj but it seems it is prepared for CogVM. For example, it expects de files cogit.c and cogit.h althought they are not generated when creating a StackVM. My question is, is there somewhere a .xcodeproj for the stackVM? or some option inside the CoreVM.xcodeproj to say that I want to compile a StackVM ? Thanks in advance, Mariano

5 11

[Cog] reproducable crash with SmallInteger as methods
by Mariano Martinez Peck 17 Dec '10

17 Dec '10

Hi Eliot. Today I can reproduce a do-it that crash Cog, when using SmallIntegers as compiled methods. The problem is actually that IT ONLY crashes when compiling in XCode with "Development". However, if I compile with "Deployment", it doesn't crash.... The code is this: SmallInteger compile: 'flushCache "emtpy"'. SmallInteger compile: 'run: aSelector with: arguments in: aReceiver Transcript show: ''something''.'. TestCase compile: 'foo ^ ''foo'' '. TestCase methodDict at: #foo put: 5. TestCase new foo. I really don't understand how this can work in "Deployment" but not in "Development" since the code is the same as I know. Maybe when debugging certain functions/methods are called that crash? Thanks for any tip. Mariano

1 3

[Cog] reproducable crash with SmallInteger as methods
by Mariano Martinez Peck 16 Dec '10

16 Dec '10

1 0

OSProcess forkSqueak partially working on Cog now
by David T. Lewis 16 Dec '10

16 Dec '10

Eliot, I've made some progress in getting OSProcess forkSqueak working with Cog. What works: No VM crashes. Forking headless Squeak works properly. All OSProcess and CommandShell unit tests green (but with intermittent errors). What does not work: Display window does not open for child Squeak after a forkSqueak. Intermittent failures in unit tests (but these are likely to be problems in the tests and/or CommandShell, i.e. they are likely exposed by but not caused by Cog). The necessary changes (so far) are: 1) Several functions in sqUnixX11.c had been declared static. These are used by XDisplayControlPlugin, so the static declarations must be removed. 2) In sqUnixHeartbeat.c, add a pthread_atfork() to restart the heartbeat thread in the child VM process following a fork. In addition to the platforms changes, the VM should include OSProcessPlugin, AioPlugin, and XDisplayControlPlugin (not just the OSProcessPlugin alone). These have all been been updated converted to use pragmas declarations, so just take the latest version of each from: http://www.squeaksource.com/OSProcessPlugin http://www.squeaksource.com/AioPlugin http://www.squeaksource.com/XDCP I am attaching patched platform files. With these patches in place, a "UnixProcess forkSqueak" produces a working child VM process with a running heartbeat thread. The child also has a new socket connection to the X server, although the display itself does not appear to be getting mapped for the child Squeak. As far as the failure to open a new X display, I suspect I'm missing something simple, but I haven't spotted what it is. If I can figure that out, I think we'll have a fully working forkSqueak. Mean time, these two platform file patches are enough to fix the main part of the problem. Dave

1 0

A Git-based VM sources repositories for you
by Igor Stasenko 15 Dec '10

15 Dec '10

Hello, community (preface) there was a discussion about using git for VM sources and recently in pharo team, we are also discussed that, and decided to go on. So i started to look for an options and found that Gitorious is best solution for us all. In contrast to github, it doesn't charging users when their repository grow beyond 300Mb in size. And its totally free for open-source projects. To be sure, that i understood thing well, i even sent mail to support to clarify some aspects of their policy and got following in answer: <<<< quote start I can't even begin to tell you how happy I am about this! Smalltalk is the coolest thing I know about computers, and I love what you have done with Squeak, thanks! <... skip technical details ...> The short version: go ahead! I'm really pleased you want to use Gitorious and I hope you'll be satisfied! Cheers, - Marius >>>>>> quote end. So, after such warm welcome, the choice was obvious :) I made a mirrors of SVN repositories for Squeak VM and Cog VM on gitorious.org. i created a group named: squeak-vm-developers http://gitorious.org/+squeak-vm-developers this group owns two projects: Squeak VM (http://gitorious.org/squeak-vm) and Cog VM (http://gitorious.org/cogvm) Any member(s) of group having an admin access to these projects , and commit rights to projects 'blessed' repositories: http://gitorious.org/cogvm/blessed http://gitorious.org/squeak-vm/blessed (yes, a single project could have multiple repositories, but for start we will use just one - a blessed ;) Now what any people from street can do: - register @ gitorious.org - go to /cogvm/blessed or /squeak-vm/blessed - click magic 'clone repository' button and from now you will have a fresh copy of 'official' repository, ready for hacking in your own corner, where you are the all powerful deity and can do anything you want without asking anyone. That's the main reason for migrating to git-based hosting: - easy for getting in - no additional administration costs - people can easily exchange the results of their own experiments without putting an 'official' repository in danger. @(John, Elior, Ian & other currently active SVN users) note: There is no pressure for migrating to git-based source code management. if you keep using SVN, no problem. I will take care with refreshing a blessed repo(s) with SVN commits. But if you want to migrate, ask me, and i will add you to 'squeak-vm-developers' group. Note that this group serves only for managing and official 'blessed' repos, and if you don't want participate, you can just live in own corner as anyone else can. This doesn't make much difference anyways :) I just wanna tell, that from now i will use own clone(s) of 'blessed' repos for experiments and of course i encouraging everyone, who wants to start hacking VM(s) to do the same. -- Best regards, Igor Stasenko AKA sig.

9 16

Re: [Pharo-project] Background changer script kills Pharo
by Henrik Sperre Johansen 14 Dec '10

14 Dec '10

On 14.12.2010 20:55, Tony Fleig wrote: > Problem solved. (Well, sort of.) > > I tracked it down to the JPEG VM plug-in. If instead the Smalltalk > JPEGReadWriter is used, the problem does not occur. I'm not sure why > it only occurs when a Delay is used though. > > Then I discovered that it does not occur in Pharo 1.1.1 either (I was > using Pharo 1.1.) So something must have changed for the better > between the versions. > > So my problem is solved and I have another reason to always use the > latest Pharo version ;) > > Thanks for your time. > > TF I think you are correct it's a problem with the plugin code being run from multiple threads. I've been able to reproduce a crash on Windows in 1.0, 1.1, 1.2 beta and Squeak 4.1 images (release and trunk) using the Squeak 4.1.1 VM. My provocative test was (seemed to happen less often with large (>3MB) images): FileStream oldFileNamed: 'trouble.jpg' do: [:img | imageStream := RWBinaryOrTextStream with: img binary contents]. 50 timesRepeat: [[ ImageReadWriter formFromStream: imageStream] forkAt: Processor userBackgroundPriority ]. Just executing the code in the forked block works just fine. Cheers, Henry

1 0

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2010