Squeak-dev November 2011

squeak-dev@lists.squeakfoundation.org

52 participants
168 discussions

Google AI competition 2011: Ants.
by Michael van der Gulik 24 Nov '11

24 Nov '11

Hi all. I made a Squeak package for the 2011 Google AI challenge (http://aichallenge.org), attached to this email. It works (but is untested by fire) but I'm giving up work on it. Basically, the AI challenge does things using shell and python scripts. Bots are compiled and then interact with the AI challenge through stdin and stdout. This much works for me. However, I was hoping that I could get the contest organisers to install Squeak in /usr/local/squeak, and then to run a user's submission, the VM would fire up the image in /usr/local/... somewhere, file in MyBot.st, run it and quit without saving anything such that no access to the file system is necessary (which is obviously a requirement for running code submitted by the general public). This doesn't work; Squeak fails to file in code if it cannot write to its .changes file. I can't be bothered to work around this issue. If anybody wants to grab my code and get the AI contest to support Smalltalk as a language then be my guest. Michael. --- Posted on the Google AI challenge forum in "Language support"... Hi. I've written a starter package for Smalltalk, attacked to this post. However, I'm giving up work on it. This is based on Squeak Smalltalk 4.2 (the current version available from http://www.squeak.org/). It works okay with the python tools except for a trivial bug: food needs to be removed from the map. I fixed this bug last night but then lost the changes somehow. However, I tried setting up a "server" version of Squeak for inclusion into the competition's VMs, and Squeak requires write access to a "changes" file (which, for the competition, would be in /usr/local/squeak/Contents/Resources/) in order to read in code, compile it and run. To me, this is the last straw; I've dodged too many issues trying to get this to work and I'm giving up. If anybody else wants to fix it up and deploy it, be my guest. Michael. -- http://gulik.pbwiki.com/

3 3

[ANN] Squeak4.3gamma-11793 ready for last cleanup
by Edgar J. De Cleene 23 Nov '11

23 Nov '11

http://ftp.squeak.org/4.3alpha/Squeak4.3gamma-11793.zip Enjoy Edgar

7 9

Building 32-bit Cairo library on Macs
by Igor Stasenko 23 Nov '11

23 Nov '11

Hello, i'd like to know, if there's anyone who can help with making 32-bit version of cairo library on macs? Because if i just do: port install cairo everything is ok, except that VM cannot use that library because it is 64bit.. And if i set build_arch to "i386" in /opt/local/etc/macports/macports.conf and run it, it also doesn't going well (see the end of mail), because of having too much dependecies from libraries which already installed and 64-bit :( Is there a way to tell port to just build stuff in a separate place.. or is there a way to build cairo library without port? sudo port install cairo Warning: port definitions are more than two weeks old, consider using selfupdate ---> Fetching pkgconfig ---> Attempting to fetch pkg-config-0.25.tar.gz from http://lil.fr.distfiles.macports.org/pkgconfig ---> Verifying checksum(s) for pkgconfig ---> Extracting pkgconfig ---> Applying patches to pkgconfig ---> Configuring pkgconfig ---> Building pkgconfig ---> Staging pkgconfig into destroot ---> Installing pkgconfig @0.25_1 ---> Deactivating pkgconfig @0.23_1 ---> Activating pkgconfig @0.25_1 ---> Cleaning pkgconfig ---> Fetching libpixman ---> Attempting to fetch pixman-0.20.0.tar.bz2 from http://lil.fr.distfiles.macports.org/libpixman ---> Verifying checksum(s) for libpixman ---> Extracting libpixman ---> Configuring libpixman ---> Building libpixman ---> Staging libpixman into destroot ---> Installing libpixman @0.20.0_0 ---> Deactivating libpixman @0.16.4_0 ---> Activating libpixman @0.20.0_0 ---> Cleaning libpixman ---> Fetching xorg-util-macros ---> Attempting to fetch util-macros-1.11.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-util-macros ---> Verifying checksum(s) for xorg-util-macros ---> Extracting xorg-util-macros ---> Configuring xorg-util-macros ---> Building xorg-util-macros ---> Staging xorg-util-macros into destroot ---> Installing xorg-util-macros @1.11.0_0 ---> Deactivating xorg-util-macros @1.5.0_0 ---> Activating xorg-util-macros @1.11.0_0 ---> Cleaning xorg-util-macros ---> Fetching xorg-xtrans ---> Attempting to fetch xtrans-1.2.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xtrans ---> Verifying checksum(s) for xorg-xtrans ---> Extracting xorg-xtrans ---> Configuring xorg-xtrans ---> Building xorg-xtrans ---> Staging xorg-xtrans into destroot ---> Installing xorg-xtrans @1.2.6_0 ---> Deactivating xorg-xtrans @1.2.5_0 ---> Activating xorg-xtrans @1.2.6_0 ---> Cleaning xorg-xtrans ---> Fetching xorg-bigreqsproto ---> Attempting to fetch bigreqsproto-1.1.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-bigreqsproto ---> Verifying checksum(s) for xorg-bigreqsproto ---> Extracting xorg-bigreqsproto ---> Configuring xorg-bigreqsproto ---> Building xorg-bigreqsproto ---> Staging xorg-bigreqsproto into destroot ---> Installing xorg-bigreqsproto @1.1.1_0 ---> Deactivating xorg-bigreqsproto @1.1.0_0 ---> Activating xorg-bigreqsproto @1.1.1_0 ---> Cleaning xorg-bigreqsproto ---> Fetching xorg-xcmiscproto ---> Attempting to fetch xcmiscproto-1.2.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xcmiscproto ---> Verifying checksum(s) for xorg-xcmiscproto ---> Extracting xorg-xcmiscproto ---> Configuring xorg-xcmiscproto ---> Building xorg-xcmiscproto ---> Staging xorg-xcmiscproto into destroot ---> Installing xorg-xcmiscproto @1.2.1_0 ---> Deactivating xorg-xcmiscproto @1.2.0_0 ---> Activating xorg-xcmiscproto @1.2.1_0 ---> Cleaning xorg-xcmiscproto ---> Fetching xorg-xextproto ---> Attempting to fetch xextproto-7.1.2.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xextproto ---> Verifying checksum(s) for xorg-xextproto ---> Extracting xorg-xextproto ---> Configuring xorg-xextproto ---> Building xorg-xextproto ---> Staging xorg-xextproto into destroot ---> Installing xorg-xextproto @7.1.2_0 ---> Deactivating xorg-xextproto @7.1.1_0 ---> Activating xorg-xextproto @7.1.2_0 ---> Cleaning xorg-xextproto ---> Fetching xorg-inputproto ---> Attempting to fetch inputproto-2.0.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-inputproto ---> Verifying checksum(s) for xorg-inputproto ---> Extracting xorg-inputproto ---> Configuring xorg-inputproto ---> Building xorg-inputproto ---> Staging xorg-inputproto into destroot ---> Installing xorg-inputproto @2.0.1_0 ---> Deactivating xorg-inputproto @2.0_0 ---> Activating xorg-inputproto @2.0.1_0 ---> Cleaning xorg-inputproto ---> Fetching xorg-xproto ---> Attempting to fetch xproto-7.0.20.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xproto ---> Verifying checksum(s) for xorg-xproto ---> Extracting xorg-xproto ---> Configuring xorg-xproto ---> Building xorg-xproto ---> Staging xorg-xproto into destroot ---> Installing xorg-xproto @7.0.20_0 ---> Deactivating xorg-xproto @7.0.16_0 ---> Activating xorg-xproto @7.0.20_0 ---> Cleaning xorg-xproto ---> Computing dependencies for xorg-libXdmcp ---> Fetching xorg-libXdmcp ---> Attempting to fetch libXdmcp-1.1.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXdmcp ---> Verifying checksum(s) for xorg-libXdmcp ---> Extracting xorg-libXdmcp ---> Configuring xorg-libXdmcp ---> Building xorg-libXdmcp ---> Staging xorg-libXdmcp into destroot ---> Computing dependencies for xorg-libXdmcp ---> Installing xorg-libXdmcp @1.1.0_0 ---> Deactivating xorg-libXdmcp @1.0.3_0 ---> Activating xorg-libXdmcp @1.1.0_0 ---> Cleaning xorg-libXdmcp ---> Computing dependencies for xorg-libXau ---> Fetching xorg-libXau ---> Attempting to fetch libXau-1.0.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXau ---> Verifying checksum(s) for xorg-libXau ---> Extracting xorg-libXau ---> Configuring xorg-libXau ---> Building xorg-libXau ---> Staging xorg-libXau into destroot ---> Computing dependencies for xorg-libXau ---> Installing xorg-libXau @1.0.6_0 ---> Deactivating xorg-libXau @1.0.5_0 ---> Activating xorg-libXau @1.0.6_0 ---> Cleaning xorg-libXau ---> Computing dependencies for libxml2 ---> Dependencies to be installed: libiconv zlib ---> Fetching libxml2 ---> Attempting to fetch libxml2-2.7.8.tar.gz from http://lil.fr.distfiles.macports.org/libxml2 ---> Verifying checksum(s) for libxml2 ---> Extracting libxml2 ---> Configuring libxml2 Error: You cannot install libxml2 for the architecture(s) i386 because Error: its dependency libiconv only contains the architecture(s) x86_64. Error: Error: Did you upgrade to a new version of Mac OS X? If so, please see Error: Error: http://trac.macports.org/wiki/Migration Error: Error: Target org.macports.configure returned: incompatible architectures in dependencies Log for libxml2 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libxml2/main.log Error: Unable to upgrade port: 1 Error: Unable to execute port: upgrade xrender failed To report a bug, see <http://guide.macports.org/#project.tickets> -- Best regards, Igor Stasenko.

2 1

Small question about ReadOnlyVariableBinding
by Ricardo Moran 23 Nov '11

23 Nov '11

Hi guys, I have just a small question: how dangerous would it be if I change a system dictionary association (such as #SerialPort) to be a read-write binding? I want to be able to provide a different abstraction for SerialPort than the one squeak provides, but I don't want to change all the code that uses it. So I though a quick and dirty way to do it would be to replace it in the SystemDictionary, like this: Smalltalk at: #SqueakSerialPort put: SerialPort. > (Smalltalk associationOrUndeclaredAt: #SerialPort) beReadWriteBinding. > Smalltalk at: #SerialPort put: MySerialPort Apart from being an ugly hack, do you think that could be dangerous in some way? Thanks in advance, Richo

3 3

OmniBrowser and ToolBuilder
by Colin Putney 22 Nov '11

22 Nov '11

Hi folks, Lately I've been working with Lukas Renggli on a new version of OmniBrowser. The main focus has been on cleaning up and isolating platform dependencies so that we can have a single version that works well on both Squeak and Pharo, while fitting comfortably into each platform's idioms. That part of it has been quite well. For proper integration with Squeak, I've been trying to get OB building its interface using ToolBuilder. It *mostly* works, but there are some areas where ToolBuilder doesn't provide the functionality that OmniBrowser needs. I had planned to extend ToolBuilder a bit with the additional functionality that OB needs, but that turns out to be more work than I anticipated, and I wasn't able to get it done before the 4.3 feature freeze. So, given the constraint of working with the Squeak 4.3 feature set, I'm not quite sure how to proceed. Here are some of the options: 1) Abandon ToolBuilder and just deal with Morphic directly. This is what OB has historically done, and I'd just be updating the old Morphic code to fit better into modern Squeak conventions. There's no longer any need to have this code work on Pharo, since Lukas is now using a separate Polymorph-specific widget package on Pharo. 2) Use ToolBuilder where possible, but customize its output. This misses the point of ToolBuilder, since it means OB won't be able to work with MVC, but at least it reduces the chance that OB will get left behind if someone adds a feature to ToolBuilder. It is a bit of "worst of both worlds" situation. 3) Use ToolBuilder, and just accept that not all the features of OB will be available until they get added to ToolBuilder. I'm not sure how much graceful degradation I can acheive, but it might not be too bad, and it'll give us (me) motivation to improve ToolBuilder for Squeak 4.4. 4) Have the OB installation process patch the base image to add the needed functionality. That would be the cleanest in terms of the OB code, but has the potential to break other packages that users might want to load. I'd really like to make this next release a solid toolset for Squeak, and fix a lot of the little annoyances that cause Squeakers to avoid it. Lukas' refactoring stuff is really excellent, better than the VisualWorks refactoring browser IMHO, and I want to make it palatable to more people in the Squeak community. I'm leaning towards option #1, because I suspect it's the mostly likely to achieve that, but I thought I'd put it out there and ask the community for advice. So, how important is ToolBuilder? What options am I missing? Cheers, Colin

6 7

Planned downtime December 6 for seaside.gemstone.com, seaside.gemstone.com/ss (GemSource), ss3.gemstone.com (SqueakSource3) and book.pharo-project.org
by Dale Henrichs 22 Nov '11

22 Nov '11

On December 6th maintenance will be performed on the internet link for the following services hosted by VMware: seaside.gemstone.com (GemSource) ss3.gemstone.com (SqueakSource3) book.pharo-project.org (Pharo the Collaboractive book) The maintenance window is between 1am and 5am PST with a scheduled 30 minutes of hard downtime. The services themselves will not be affected as it is only the internet link that is undergoing maintenance. The date and times are subject to change, but I thought I'd broadcast a heads up as soon as I got the information. Dale

1 0

ReleaseBuilderTrunk errors
by Chris Cunnington 22 Nov '11

22 Nov '11

http://www.16r.ca/CroquetScreenSnapz001.jpg http://www.16r.ca/CroquetScreenSnapz002.jpg Practicing with: ReleaseBuilderTrunk prepareNewBuild I get the errors above. They show up when I've made some changes to the class side senders. I can't see it being anything I'm doing as I'm changing '2's to '3's and such. Thanks, Chris

1 0

Daily Commit Log
by commits＠source.squeak.org 22 Nov '11

22 Nov '11

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2011-November/005102.h… Name: Monticello-cmm.488 Ancestors: Monticello-bf.487, Monticello-cmm.462 Fix MC Configurations not always appearing in repository list. =============================================

1 0

How to build a standard Unix interpreter VM on Linux using a Squeak trunk image
by David T. Lewis 21 Nov '11

21 Nov '11

This is a topic that deserves an occasional update, so here is an updated step-by-step recipe for building with Squeak on Linux. These instructions are saved on the swiki at <http://wiki.squeak.org/squeak/6177> Start with a fresh image such as http://ftp.squeak.org/4.3alpha/Squeak4.3gamma-11793.zip (any recent Squeak image will do). Open a new Morphic project in which to work, and enter the project. Open a new workspace for taking notes as you work, and a transcript to display any transcript output that might appear. Open a Monticello browser. In the Monticello browser, add a new repository (+Repository button). Select "HTTP" repository type, and edit the repository information as follows: MCHttpRepository location: 'http://www.squeaksource.com/VMMaker' user: '' password: '' Open the new repository (select the new entry and click the Open button to get a new repository browser). In the repository browser, select category "update" from the list in the left panel, and select the top entry in the right panel (update-dtl.9.mcm as of this writing). Click the "Load" button to load VMMaker. This will load VMMaker and various related packages and plugins. This will load a base version of these packages (but you do not yet have the latest updates, see the next step below). You can see a version identification for your VMMaker package by evaluating "VMMaker versionString" in your workspace: VMMaker versionString ==> '4.7.9' In the workspace, evaluate the expression "VMMaker updateFromServer". This will update VMMaker and the other packages to the most up to date versions. During the merge process, a merge browser will open with a label such as "Merging FFI-Pools-eem.3". Highlight the entries and click "Keep", then click the "Merge" button to accept the merge and proceed (this merge conflict will not effect your VM, so it is safe to ignore it and proceed). When the update process is complete, you will have the latest VMMaker version: VMMaker versionString ==> '4.7.14' Save your image. Your image is now prepared for VM code generation, so the next steps will be to load the platform source code that is required for code generation and VM building. In a Linux terminal window (outside of Squeak), change your directory to your working Squeak directory (the same directory that you are using to run your image. lewis@linux-jh8m:~> cd squeak/Squeak4.3 lewis@linux-jh8m:~/squeak/Squeak4.3> Check out an up to date copy of the platforms source code. You will need to have Subversion installed on your Linux system: lewis@linux-jh8m:~/squeak/Squeak4.3> svn co http://squeakvm.org/svn/squeak/trunk <lots of messages snipped> Checked out revision 2515. lewis@linux-jh8m:~/squeak/Squeak4.3> svn co http://squeakvm.org/svn/squeak/trunk This will place all of the platform sources in a subdirectory called trunk/platforms. It is easier for VMMaker to find this directory if the platforms directory is in directly in your Squeak directory, so use a symbolic link to make it so: lewis@linux-jh8m:~/squeak/Squeak4.3> ln -s trunk/platforms platforms The platforms sources are now ready for use, so return to your Squeak image to generate your VM source code. Open a VMMaker tool withy world menu -> open... -> VMMaker Click the Help button and have a quick look at the help information. You can come back to it later to read in more detail. A list of available plugins appears in the left panel ("Plugins not built"). You can drag entiries from this panel into the "Internal Plugins" panel or the "External Plugins" panel, or you can right click on the panel and use the menu to copy all plugins from one panel to another (plugins that cannot be built on your platform will remain in the "Plugins not built" panel). We are building our first VM, so we will select just a few important plugins to build and omit many others for now. After you are confident that you can build a VM, you can add other plugins and any operating system libraries that may be needed to support them. You can also use a VMMaker configuration file to load a saved configuration, but for now we will do the work by hand to show how it is done. Use the mouse to drag and drop the following plugin entries from the "Plugins not built" panel to the "Internal plugins" panel. BalloonEnginePlugin BitBltSimulation DeflatePlugin FilePlugin LargeIntegersPlugin LocalePlugin SecurityPlugin SocketPlugin Now add some external plugins by dragging the following entries to the "External plugins" panel: UUIDPlugin UnixAioPlugin UnixOSProcessPlugin XDisplayControlPlugin Click the "Clean out" button to make sure the output directory is empty. This is not really necessary now, but it is good practice, and you will want to do it any time you want to guarantee that you are generating a complete fresh copy of the VM sources. In the "Generate:" panel, click the "Entire" button. This will generate all of the VM and plugin source code. In other words, it will translate the Smalltalk classes in your image into C code, and store the resulting source code in the "src" directory in your Squeak directory. This generated source, in combination with the platforms source code that you downloaded from the Subversion repository, is the complete source code for your new Squeak VM. Now go back to your Linux terminal window to compile and install the VM. You will need to have the CMake package installed on your Linux system, so make sure this is done before proceeding. You should now have all necessary sources in the "platforms" and "src" directories in your Squeak working directory: lewis@linux-jh8m:~/squeak/Squeak4.3> ls -ltd platforms src drwxr-xr-x 4 lewis users 4096 2011-11-19 10:10 src lrwxrwxrwx 1 lewis users 15 2011-11-19 09:39 platforms -> trunk/platforms Create a "build" directory for building the VM, and change into that directory: lewis@linux-jh8m:~/squeak/Squeak4.3> mkdir build lewis@linux-jh8m:~/squeak/Squeak4.3> cd build lewis@linux-jh8m:~/squeak/Squeak4.3/build> We will first run a configuration procedure that uses CMake to configure the sources for your system. You will find documention for this in platforms/unix/CMake.txt. The script that runs this procedure has introductory help, so read this first: lewis@linux-jh8m:~/squeak/Squeak4.3/build> ../platforms/unix/cmake/configure --help Now, from your empty build directory, run the actual configuration process. The parameters specify the location of the generated sources, and also specify that GL libaries should be avoided (they are not needed for this simple build, and might cause problems if you do not have the necessary libraries in place). If you are using a 64-bit operating system, this configuration will build a 64-bit VM (see the configuration help above if you want to specify CFLAGS to build a 32-bit VM, which you may later want to do if you are building some of the plugins that work in 32-bit mode). lewis@linux-jh8m:~/squeak/Squeak4.3/build> ../platforms/unix/cmake/configure --src=../src --without-gl When the configuration is complete, use make to build the VM: lewis@linux-jh8m:~/squeak/Squeak4.3/build> make If you have any errors or problems with the build, you may need to do some troubleshooting. In most cases the problem will relate to missing development software that you will need to install on your Linux system. When the build is complete, your new VM is read to be installed. lewis@linux-jh8m:~/squeak/Squeak4.3/build> make install Depending on the security settings of your system, you may need to log in as root (or use sudo) to perform this last step (but never use root access for any of the other build steps described above). Your new Squeak VM is now built and installed, ready to be run as /usr/local/bin/squeak. You can verify the version of the VM you are running as follows: lewis@linux-jh8m:~/squeak/Squeak4.3/build> squeak -version 4.7.14-2515 #1 XShm Sat Nov 19 10:27:11 EST 2011 gcc 4.5.0 Linux linux-jh8m 2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 x86_64 x86_64 x86_64 GNU/Linux plugin path: /usr/local/lib/squeak/4.7.14-2515 [default: /usr/local/lib/squeak/4.7.14-2515/] Congratulations, you are now a VM builder. You will probably want to add some more plugins, and you can save and load your VMMaker configurations for various combinations of plugins with the "Load" and "Save" buttons on your VMMaker window. For reference, here is a configuration file that matches the configuration of recent official Unix Squeak VMs on www.squeakvm.org (note that you will need to locate and install KedamaPlugin and GStreamer plugin to build a VM that fully matches the standard Unix VM). Contents of standard-vmmaker-unix.config file: #(#(#ADPCMCodecPlugin #AsynchFilePlugin #BMPReadWriterPlugin #BalloonEnginePlugin #BitBltSimulation #CroquetPlugin #DSAPlugin #DeflatePlugin #DropPlugin #FFTPlugin #FT2Plugin #FilePlugin #FloatArrayPlugin #FloatMathPlugin #GeniePlugin #JPEGReadWriter2Plugin #JPEGReaderPlugin #JoystickTabletPlugin #KlattSynthesizerPlugin #LargeIntegersPlugin #LocalePlugin #MD5Plugin #Matrix2x3Plugin #MiscPrimitivePlugin #RandPlugin #RePlugin #SHA256Plugin #SecurityPlugin #SerialPlugin #SlangTestPlugin #SlangTestSupportPlugin #SocketPlugin #SoundCodecPlugin #SoundGenerationPlugin #SoundPlugin #StarSqueakPlugin #SurfacePlugin ) #(#B3DAcceleratorPlugin #B3DEnginePlugin #ClipboardExtendedPlugin #DBusPlugin #FFIPlugin #FileCopyPlugin #GStreamerPlugin #HostWindowPlugin #KedamaPlugin #KedamaPlugin2 #MIDIPlugin #Mpeg3Plugin #RomePlugin #UUIDPlugin #UnixAioPlugin #UnixOSProcessPlugin #XDisplayControlPlugin ) true false 'unix' 'src' 'platforms' 4 true true 'Interpreter' )

3 4

New Cog VMs available [was [squeak-dev] VM cog crash]
by Eliot Miranda 21 Nov '11

21 Nov '11

Hi All, new VMs at http://www.mirandabanda.org/files/Cog/VM/VM.r2515/. These fix a code generator bug and as a result produce slightly better code in rare circumstances. Anyway, Hans' case below will no longer crash the VM :) Enjoy. On Thu, Nov 17, 2011 at 5:38 AM, Baveco, Hans <Hans.Baveco(a)wur.nl> wrote: > I managed to crash the (latest) cog VM consistently, producing the > attached crash dump (containing two crashes). > Debugging the code carefully I found that somewhere in the process of > setting an instance variable of an object at the top of a tree-like > structure, by traversing the tree downwards and back (lazy initializing > instance variables), a clearly wrong method was executed: > > setCenter: aPoint > > center := center > > > after correcting this the crashes didn't occur anymore. > Not sure how important this is, but surprising it was, though! > > Hans > > > > -- best, Eliot

4 3

← Newer
1
2
3
4
5
6
7
8
...
17
Older →

Jump to page: