v3.9.0 (2018-03-04)
-
Bootstrap 4 support (#4032, #4065, thx @GeekJosh)
-
add OptionsInput to the fullcalendar.d.ts exports (#4040, #4006)
-
columnHeaderFormat/columnHeaderHtml/columnHeaderText in .d.ts file (#4061, #4085)
-
list-view auto-height not working (#3346, #4071, thx @WhatTheBuild)
-
bump momentjs minimum version to 2.20.1, for locale fixes (#4014)
-
swedish week header translation fix (#4082)
-
dutch year translation (#4069)
v3.8.2 (2018-01-30)
Bugfixes:
-
Fix TypeScript definitions file with strictNullChecks (#4035)
v3.8.1 (2018-01-28)
Bugfixes:
-
TypeScript definition file not compatible with noImplicitAny (#4017)
-
ES6 classes are not supported for grid class (#3437)
-
day numbers in month view should be localized (#3339)
-
select helper is resizable, causes js error (#3764)
-
selecting over existing select helper causes js error (#4031)
-
eventOrder doesn't work on custom fields (#3950)
-
aria label on button icons (#4023)
-
dynamic option changes to select/overlap/allow doesn't cause rerender
Locales:
-
added Georgian (#3994)
-
added Bosnian (#4029)
v3.8.0 (2017-12-18)
-
new settings for month/agenda/basic views (#3078):
-
`columnHeaderFormat` (renamed from `columnFormat`)
-
`columnHeaderText`
-
`columnHeaderHtml`
-
-
TypeScript definition file (fullcalendar.d.ts) included in npm package (#3889)
-
codebase using SASS, though not taking advantage of it yet (#3463)
-
codebase fully ported to TypeScript / Webpack
-
Afrikaans locale fix (#3862)
v3.7.0 (2017-11-13)
Bugfixes:
-
`render` method does not re-adjust calendar dimension (#3893)
-
when custom view navigates completely into hidden weekends, JS error ([scheduler-375])
Other:
-
in themes.html demo, fixed broken Bootswatch themes (#3917)
-
moved JavaScript codebase over to TypeScript (same external API; embedded typedefs coming soon)
[scheduler-375]: github.com/fullcalendar/fullcalendar-scheduler/issues/375
v3.6.2 (2017-10-23)
Bugfixes:
-
Google Calendar event sources not calling `loading` callback (#3884)
-
`eventDataTransform` w/ eventConstraint shouldn't be called during event resizing (#3859)
-
`navLinks` would go to the previously navigated date (#3869)
-
`nowIndicator` arrow would repeatedly render (#3872)
-
fc-content-skeleton DOM element would repeatedly render on navigation in agenda view
v3.6.1 (2017-10-11)
Bugfixes:
-
JSON feed event sources always requesting current page (#3865)
-
multi-day events appearing multiple times in more+ popover (#3856)
v3.6.0 (2017-10-10)
Features:
-
`agendaEventMinHeight` for guaranteeing height (#961, #3788) thx @Stafie
-
`columnHeader` can be set to `false` to hide headings (#3438, #3787) thx @caseyjhol
-
export all View classes (#2851, #3831)
-
`updateEvent`, update complex attributes (#2864)
-
Albanian locale (#3847) thx @alensaqe
Bugfixes:
-
objects used as non-standard Event properties ignored by `updateEvent` (#3839)
-
listDay error if event goes over period (#3843)
-
`validDays` with `hiddenDays`, js error when no days active (#3846)
-
json feed Event Source object no longer has `url` property (#3845)
-
`updateEvent`, allDay to timed, when no end, wrong end date (#3144)
-
`removeEvents` by `_id` stopped working (#3828)
-
correct `this` context in FuncEventSource (#3848) thx @declspec
-
js event not received in unselect callback when selecting another cell (#3832)
Incompatibilities:
-
The `viewRender` callback might now be fired AFTER events have been rendered to the DOM. However, the eventRender/eventAfterRender/eventAfterAllRender callbacks will always be fired after `viewRender`, just as before.
-
The internal `Grid` class (accessed via `$.fullCalendar.Grid`) has been removed. For monkeypatching, use DayGrid/TimeGrid directly.
v3.5.1 (2017-09-06)
-
fixed loading trigger not firing (#3810)
-
fixed overaggressively fetching events, on option changes (#3820)
-
fixed event object `date` property being discarded (tho still parsed) (#3819)
-
fixed event object `_id` property being discarded (#3811)
v3.5.0 (2017-08-30)
Features:
-
Bootstrap 3 theme support (#2334, #3566)
- via `themeSystem: 'bootstrap3'` (the `theme` option is deprecated) - new `bootstrapGlyphicons` option - jQuery UI "Cupertino" theme no longer included in zip archive - improved theme switcher on demo page (#1436) (big thanks to @joankaradimov)
-
25% event rendering performance improvement across the board (#2524)
-
console message for unknown method/calendar (#3253)
-
Serbian cyrilic/latin (#3656)
-
available via Packagist (#2999, #3617)
Bugfixes:
-
slot time label invisible when minTime starts out of alignment (#2786)
-
bug with inverse-background event rendering when out of range (#3652)
-
wrongly disabled prev/next when current date outside of validRange (#3686, #3651)
-
updateEvent, error when changing allDay from false to true (#3518)
-
updateEvent doesn't support ID changes (#2928)
-
Promise then method doesn't forward result (#3744)
-
Korean typo (#3693)
-
fixed switching from any view to listview, eventAfterRender isn't called (#3751)
Incompatibilities:
-
Event Objects obtained from clientEvents or various callbacks are no longer references to internally used objects. Rather, they are static object copies.
-
`clientEvents` method no longer returns events in same order as received. Do not depend on order.
v3.4.0 (2017-04-27)
-
composer.json for Composer (PHP package manager) (#3617)
-
fix toISOString for locales with non-trivial postformatting (#3619)
-
fix for nested inverse-background events (#3609)
-
Estonian locale (#3600)
-
fixed Latvian localization (#3525)
-
internal refactor of async systems
v3.3.1 (2017-04-01)
Bugfixes:
-
stale calendar title when navigate away from then back to the a view (#3604)
-
js error when gotoDate immediately after calendar initialization (#3598)
-
agenda view scrollbars causes misalignment in jquery 3.2.1 (#3612)
-
navigation bug when trying to navigate to a day of another week (#3610)
-
dateIncrement not working when duration and dateIncrement have different units
v3.3.0 (2017-03-23)
Features:
-
`visibleRange` - complete control over view's date range (#2847, #3105, #3245)
-
`validRange` - restrict date range (#429)
-
`changeView` - pass in a date or visibleRange as second param (#3366)
-
`dateIncrement` - customize prev/next jump (#2710)
-
`dateAlignment` - custom view alignment, like start-of-week (#3113)
-
`dayCount` - force a fixed number-of-days, even with hiddenDays (#2753)
-
`showNonCurrentDates` - option to hide day cells for prev/next months (#437)
-
can define a defaultView with a duration/visibleRange/dayCount with needing to create a custom view in the `views` object. Known as a “Generic View”.
Behavior Changes:
-
when custom view is specified with duration `{days:7}`, it will no longer align with the start of the week. (#2847)
-
when `gotoDate` is called on a custom view with a duration of multiple days, the view will always shift to begin with the given date. (#3515)
Bugfixes:
-
event rendering when excessive `minTime`/`maxTime` (#2530)
-
event dragging not shown when excessive `minTime`/`maxTime` (#3055)
-
excessive `minTime`/`maxTime` not reflected in event fetching (#3514)
- when minTime is negative, or maxTime beyond 24 hours, when event data is requested via a function or a feed, the given data params will have time parts.
-
external event dragging via touchpunch broken (#3544)
-
can't make an immediate new selection after existing selection, with mouse. introduced in v3.2.0 (#3558)
v3.2.0 (2017-02-14)
Features:
-
`selectMinDistance`, threshold before a mouse selection begins (#2428)
Bugfixes:
-
iOS 10, unwanted scrolling while dragging events/selection (#3403)
-
dayClick triggered when swiping on touch devices (#3332)
-
dayClick not functioning on Firefix mobile (#3450)
-
title computed incorrectly for views with no weekends (#2884)
-
unwanted scrollbars in month-view when non-integer width (#3453, #3444)
-
incorrect date formatting for locales with non-standlone month/day names (#3478)
-
date formatting, incorrect omission of trailing period for certain locales (#2504, #3486)
-
formatRange should collapse same week numbers (#3467)
-
Taiwanese locale updated (#3426)
-
Finnish noEventsMessage updated (#3476)
-
Croatian (hr) buttonText is blank (#3270)
-
JSON feed PHP example, date range math bug (#3485)
v3.1.0 (2016-12-05)
-
experimental support for implicitly batched (“debounced”) event rendering (#2938)
- `eventRenderWait` (off by default)
-
new `footer` option, similar to header toolbar (#654, #3299)
-
event rendering batch methods (#3351):
- `renderEvents` - `updateEvents`
-
more granular touch settings (#3377):
- `eventLongPressDelay` - `selectLongPressDelay`
-
eventDestroy not called when removing the popover (#3416, #3419)
-
print stylesheet and gcal extension now offered as minified (#3415)
-
fc-today in agenda header cells (#3361, #3365)
-
height-related options in tandem with other options (#3327, #3384)
-
Kazakh locale (#3394)
-
Afrikaans locale (#3390)
-
internal refactor related to timing of rendering and firing handlers. calls to rerender the current date-range and events from within handlers might not execute immediately. instead, will execute after handler finishes.
v3.0.1 (2016-09-26)
Bugfixes:
-
list view rendering event times incorrectly (#3334)
-
list view rendering events/days out of order (#3347)
-
events with no title rendering as “undefined”
-
add .fc scope to table print styles (#3343)
-
“display no events” text fix for German (#3354)
v3.0.0 (2016-09-04)
Features:
-
List View (#560)
- new views: `listDay`, `listWeek`, `listMonth`, `listYear`, and simply `list` - `listDayFormat` - `listDayAltFormat` - `noEventsMessage`
-
Clickable day/week numbers for easier navigation (#424)
- `navLinks` - `navLinkDayClick` - `navLinkWeekClick`
-
Programmatically allow/disallow user interactions:
- `eventAllow` (#2740) - `selectAllow` (#2511)
-
Option to display week numbers in cells (#3024)
- `weekNumbersWithinDays` (set to `true` to activate)
-
When week calc is ISO, default first day-of-week to Monday (#3255)
-
Macedonian locale (#2739)
-
Malay locale
Breaking Changes:
-
IE8 support dropped
-
jQuery: minimum support raised to v2.0.0
-
MomentJS: minimum support raised to v2.9.0
-
`lang` option renamed to `locale`
-
dist files have been renamed to be more consistent with MomentJS:
- `lang/` -> `locale/` - `lang-all.js` -> `locale-all.js`
-
behavior of moment methods no longer affected by ambiguousness:
- `isSame` - `isBefore` - `isAfter`
-
View-Option-Hashes no longer supported (deprecated in 2.2.4)
-
removed `weekMode` setting
-
removed `axisFormat` setting
-
DOM structure of month/basic-view day cell numbers changed
Bugfixes:
-
`$.fullCalendar.version` incorrect (#3292)
Build System:
-
using gulp instead of grunt (faster)
-
using npm internally for dependencies instead of bower
-
changed repo directory structure
v2.9.1 (2016-07-31)
-
multiple definitions for businessHours (#2686)
-
businessHours for single day doesn't display weekends (#2944)
-
height/contentHeight can accept a function or 'parent' for dynamic value (#3271)
-
fix +more popover clipped by overflow (#3232)
-
fix +more popover positioned incorrectly when scrolled (#3137)
-
Norwegian Nynorsk translation (#3246)
-
fix isAnimating JS error (#3285)
v2.9.0 (2016-07-10)
-
Setters for (almost) all options (#564). See [docs](fullcalendar.io/docs/utilities/dynamic_options/) for more info.
-
Travis CI improvements (#3266)
v2.8.0 (2016-06-19)
-
getEventSources method (#3103, #2433)
-
getEventSourceById method (#3223)
-
refetchEventSources method (#3103, #1328, #254)
-
removeEventSources method (#3165, #948)
-
prevent flicker when refetchEvents is called (#3123, #2558)
-
fix for removing event sources that share same URL (#3209)
-
jQuery 3 support (#3197, #3124)
-
Travis CI integration (#3218)
-
EditorConfig for promoting consistent code style (#141)
-
use en dash when formatting ranges (#3077)
-
height:auto always shows scrollbars in month view on FF (#3202)
-
new languages:
- Basque (#2992) - Galician (#194) - Luxembourgish (#2979)
v2.7.3 (2016-06-02)
internal enhancements that plugins can benefit from:
-
EventEmitter not correctly working with stopListeningTo
-
normalizeEvent hook for manipulating event data
v2.7.2 (2016-05-20)
-
fixed desktops/laptops with touch support not accepting mouse events for dayClick/dragging/resizing (#3154, #3149)
-
fixed dayClick incorrectly triggered on touch scroll (#3152)
-
fixed touch event dragging wrongfully beginning upon scrolling document (#3160)
-
fixed minified JS still contained comments
-
UI change: mouse users must hover over an event to reveal its resizers
v2.7.1 (2016-05-01)
-
dayClick not firing on touch devices (#3138)
-
icons for prev/next not working in MS Edge (#2852)
-
fix bad languages troubles with firewalls (#3133, #3132)
-
update all dev dependencies (#3145, #3010, #2901, #251)
-
git-ignore npm debug logs (#3011)
-
misc automated test updates (#3139, #3147)
-
Google Calendar htmlLink not always defined (#2844)
v2.7.0 (2016-04-23)
touch device support (#994):
- smoother scrolling - interactions initiated via "long press": - event drag-n-drop - event resize - time-range selecting - `longPressDelay`
v2.6.1 (2016-02-17)
-
make `nowIndicator` positioning refresh on window resize
v2.6.0 (2016-01-07)
-
current time indicator (#414)
-
bundled with most recent version of moment (2.11.0)
-
UMD wrapper around lang files now handles commonjs (#2918)
-
fix bug where external event dragging would not respect eventOverlap
-
fix bug where external event dropping would not render the whole-day highlight
v2.5.0 (2015-11-30)
-
internal timezone refactor. fixes #2396, #2900, #2945, #2711
-
internal “grid” system refactor. improved API for plugins.
v2.4.0 (2015-08-16)
-
add new buttons to the header via `customButtons` ([225])
-
control stacking order of events via `eventOrder` ([364])
-
control frequency of slot text via `slotLabelInterval` ([946])
-
`displayEventTime` ([1904])
-
`on` and `off` methods ([1910])
-
renamed `axisFormat` to `slotLabelFormat`
[225]: code.google.com/p/fullcalendar/issues/detail?id=225 [364]: code.google.com/p/fullcalendar/issues/detail?id=364 [946]: code.google.com/p/fullcalendar/issues/detail?id=946 [1904]: code.google.com/p/fullcalendar/issues/detail?id=1904 [1910]: code.google.com/p/fullcalendar/issues/detail?id=1910
v2.3.2 (2015-06-14)
-
minor code adjustment in preparation for plugins
v2.3.1 (2015-03-08)
-
Fix week view column title for en-gb ([PR220])
-
Publish to NPM ([2447])
-
Detangle bower from npm package ([PR179])
[PR220]: github.com/arshaw/fullcalendar/pull/220 [2447]: code.google.com/p/fullcalendar/issues/detail?id=2447 [PR179]: github.com/arshaw/fullcalendar/pull/179
v2.3.0 (2015-02-21)
-
internal refactoring in preparation for other views
-
businessHours now renders on whole-days in addition to timed areas
-
events in “more” popover not sorted by time ([2385])
-
avoid using moment's deprecated zone method ([2443])
-
destroying the calendar sometimes causes all window resize handlers to be unbound ([2432])
-
multiple calendars on one page, can't accept external elements after navigating ([2433])
-
accept external events from jqui sortable ([1698])
-
external jqui drop processed before reverting ([1661])
-
IE8 fix: month view renders incorrectly ([2428])
-
IE8 fix: eventLimit:true wouldn't activate “more” link ([2330])
-
IE8 fix: dragging an event with an href
-
IE8 fix: invisible element while dragging agenda view events
-
IE8 fix: erratic external element dragging
[2385]: code.google.com/p/fullcalendar/issues/detail?id=2385 [2443]: code.google.com/p/fullcalendar/issues/detail?id=2443 [2432]: code.google.com/p/fullcalendar/issues/detail?id=2432 [2433]: code.google.com/p/fullcalendar/issues/detail?id=2433 [1698]: code.google.com/p/fullcalendar/issues/detail?id=1698 [1661]: code.google.com/p/fullcalendar/issues/detail?id=1661 [2428]: code.google.com/p/fullcalendar/issues/detail?id=2428 [2330]: code.google.com/p/fullcalendar/issues/detail?id=2330
v2.2.7 (2015-02-10)
-
view.title wasn't defined in viewRender callback ([2407])
-
FullCalendar versions >= 2.2.5 brokenness with Moment versions <= 2.8.3 ([2417])
-
Support Bokmal Norwegian language specifically ([2427])
[2407]: code.google.com/p/fullcalendar/issues/detail?id=2407 [2417]: code.google.com/p/fullcalendar/issues/detail?id=2417 [2427]: code.google.com/p/fullcalendar/issues/detail?id=2427
v2.2.6 (2015-01-11)
-
Compatibility with Moment v2.9. Was breaking GCal plugin ([2408])
-
View object's `title` property mistakenly omitted ([2407])
-
Single-day views with hiddens days could cause prev/next misbehavior ([2406])
-
Don't let the current date ever be a hidden day (solves [2395])
-
Hebrew locale ([2157])
[2408]: code.google.com/p/fullcalendar/issues/detail?id=2408 [2407]: code.google.com/p/fullcalendar/issues/detail?id=2407 [2406]: code.google.com/p/fullcalendar/issues/detail?id=2406 [2395]: code.google.com/p/fullcalendar/issues/detail?id=2395 [2157]: code.google.com/p/fullcalendar/issues/detail?id=2157
v2.2.5 (2014-12-30)
-
`buttonText` specified for custom views via the `views` option
- bugfix: wrong default value, couldn't override default - feature: default value taken from locale
v2.2.4 (2014-12-29)
-
Arbitrary durations for basic/agenda views with the `views` option ([692])
-
Specify view-specific options using the `views` option. fixes [2283]
-
Deprecate view-option-hashes
-
Formalize and expose View API ([1055])
-
updateEvent method, more intuitive behavior. fixes [2194]
[692]: code.google.com/p/fullcalendar/issues/detail?id=692 [2283]: code.google.com/p/fullcalendar/issues/detail?id=2283 [1055]: code.google.com/p/fullcalendar/issues/detail?id=1055 [2194]: code.google.com/p/fullcalendar/issues/detail?id=2194
v2.2.3 (2014-11-26)
-
removeEventSource with Google Calendar object source, would not remove ([2368])
-
Events with invalid end dates are still accepted and rendered ([2350], [2237], [2296])
-
Bug when rendering business hours and navigating away from original view ([2365])
-
Links to Google Calendar events will use current timezone ([2122])
-
Google Calendar plugin works with timezone names that have spaces
-
Google Calendar plugin accepts person email addresses as calendar IDs
-
Internally use numeric sort instead of alphanumeric sort ([2370])
[2368]: code.google.com/p/fullcalendar/issues/detail?id=2368 [2350]: code.google.com/p/fullcalendar/issues/detail?id=2350 [2237]: code.google.com/p/fullcalendar/issues/detail?id=2237 [2296]: code.google.com/p/fullcalendar/issues/detail?id=2296 [2365]: code.google.com/p/fullcalendar/issues/detail?id=2365 [2122]: code.google.com/p/fullcalendar/issues/detail?id=2122 [2370]: code.google.com/p/fullcalendar/issues/detail?id=2370
v2.2.2 (2014-11-19)
-
Fixes to Google Calendar API V3 code
- wouldn't recognize a lone-string Google Calendar ID if periods before the @ symbol - removeEventSource wouldn't work when given a Google Calendar ID
v2.2.1 (2014-11-19)
-
Migrate Google Calendar plugin to use V3 of the API ([1526])
[1526]: code.google.com/p/fullcalendar/issues/detail?id=1526
v2.2.0 (2014-11-14)
-
Background events. Event object's `rendering` property ([144], [1286])
-
`businessHours` option ([144])
-
Controlling where events can be dragged/resized and selections can go ([396], [1286], [2253])
- `eventOverlap`, `selectOverlap`, and similar - `eventConstraint`, `selectConstraint`, and similar
-
Improvements to dragging and dropping external events ([2004])
- Associating with real event data. used with `eventReceive` - Associating a `duration`
-
Performance boost for moment creation
- Be aware, FullCalendar-specific methods now attached directly to global moment.fn - Helps with [issue 2259][2259]
-
Reintroduced forgotten `dropAccept` option ([2312])
[144]: code.google.com/p/fullcalendar/issues/detail?id=144 [396]: code.google.com/p/fullcalendar/issues/detail?id=396 [1286]: code.google.com/p/fullcalendar/issues/detail?id=1286 [2004]: code.google.com/p/fullcalendar/issues/detail?id=2004 [2253]: code.google.com/p/fullcalendar/issues/detail?id=2253 [2259]: code.google.com/p/fullcalendar/issues/detail?id=2259 [2312]: code.google.com/p/fullcalendar/issues/detail?id=2312
v2.1.1 (2014-08-29)
-
removeEventSource not working with array ([2203])
-
mouseout not triggered after mouseover+updateEvent ([829])
-
agenda event's render with no <a> href, not clickable ([2263])
[2203]: code.google.com/p/fullcalendar/issues/detail?id=2203 [829]: code.google.com/p/fullcalendar/issues/detail?id=829 [2263]: code.google.com/p/fullcalendar/issues/detail?id=2263
v2.1.0 (2014-08-25)
Large code refactor with better OOP, better code reuse, and more comments. **No more reliance on jQuery UI** for event dragging, resizing, or anything else.
Significant changes to HTML/CSS skeleton:
-
Leverages tables for liquid rendering of days and events. No costly manual repositioning ([809])
-
*Backwards-incompatibilities*:
- **Many classNames have changed. Custom CSS will likely need to be adjusted.** - IE7 definitely not supported anymore - In `eventRender` callback, `element` will not be attached to DOM yet - Events are styled to be one line by default ([1992]). Can be undone through custom CSS, but not recommended (might get gaps [like this][111] in certain situations).
A “more…” link when there are too many events on a day ([304]). Works with month and basic views as well as the all-day section of the agenda views. New options:
-
`eventLimit`. a number or `true`
-
`eventLimitClick`. the `“popover`” value will reveal all events in a raised panel (the default)
-
`eventLimitText`
-
`dayPopoverFormat`
Changes related to height and scrollbars:
-
`aspectRatio`/`height`/`contentHeight` values will be honored *no matter what*
- If too many events causing too much vertical space, scrollbars will be used ([728]). This is default behavior for month view (**backwards-incompatibility**) - If too few slots in agenda view, view will stretch to be the correct height ([2196])
-
`'auto'` value for `height`/`contentHeight` options. If content is too tall, the view will vertically stretch to accomodate and no scrollbars will be used ([521]).
-
Tall weeks in month view will borrow height from other weeks ([243])
-
Automatically scroll the view then dragging/resizing an event ([1025], [2078])
-
New `fixedWeekCount` option to determines the number of weeks in month view
- Supersedes `weekMode` (**deprecated**). Instead, use a combination of `fixedWeekCount` and one of the height options, possibly with an `'auto'` value
Much nicer, glitch-free rendering of calendar *for printers* ([35]). Things you might not expect:
-
Buttons will become hidden
-
Agenda views display a flat list of events where the time slots would be
Other issues resolved along the way:
-
Space on right side of agenda events configurable through CSS ([204])
-
Problem with window resize ([259])
-
Events sorting stays consistent across weeks ([510])
-
Agenda's columns misaligned on wide screens ([511])
-
Run `selectHelper` through `eventRender` callbacks ([629])
-
Keyboard access, tabbing ([637])
-
Run resizing events through `eventRender` ([714])
-
Resize an event to a different day in agenda views ([736])
-
Allow selection across days in agenda views ([778])
-
Mouseenter delegated event not working on event elements ([936])
-
Agenda event dragging, snapping to different columns is erratic ([1101])
-
Android browser cuts off Day view at 8 PM with no scroll bar ([1203])
-
Don't fire `eventMouseover`/`eventMouseout` while dragging/resizing ([1297])
-
Customize the resize handle text (“=”) ([1326])
-
If agenda event is too short, don't overwrite `.fc-event-time` ([1700])
-
Zooming calendar causes events to misalign ([1996])
-
Event destroy callback on event removal ([2017])
-
Agenda views, when RTL, should have axis on right ([2132])
-
Make header buttons more accessibile ([2151])
-
daySelectionMousedown should interpret OSX ctrl+click as a right mouse click ([2169])
-
Best way to display time text on multi-day events *with times* ([2172])
-
Eliminate table use for header layout ([2186])
-
Event delegation used for event-related callbacks (like `eventClick`). Speedier.
[35]: code.google.com/p/fullcalendar/issues/detail?id=35 [204]: code.google.com/p/fullcalendar/issues/detail?id=204 [243]: code.google.com/p/fullcalendar/issues/detail?id=243 [259]: code.google.com/p/fullcalendar/issues/detail?id=259 [304]: code.google.com/p/fullcalendar/issues/detail?id=304 [510]: code.google.com/p/fullcalendar/issues/detail?id=510 [511]: code.google.com/p/fullcalendar/issues/detail?id=511 [521]: code.google.com/p/fullcalendar/issues/detail?id=521 [629]: code.google.com/p/fullcalendar/issues/detail?id=629 [637]: code.google.com/p/fullcalendar/issues/detail?id=637 [714]: code.google.com/p/fullcalendar/issues/detail?id=714 [728]: code.google.com/p/fullcalendar/issues/detail?id=728 [736]: code.google.com/p/fullcalendar/issues/detail?id=736 [778]: code.google.com/p/fullcalendar/issues/detail?id=778 [809]: code.google.com/p/fullcalendar/issues/detail?id=809 [936]: code.google.com/p/fullcalendar/issues/detail?id=936 [1025]: code.google.com/p/fullcalendar/issues/detail?id=1025 [1101]: code.google.com/p/fullcalendar/issues/detail?id=1101 [1203]: code.google.com/p/fullcalendar/issues/detail?id=1203 [1297]: code.google.com/p/fullcalendar/issues/detail?id=1297 [1326]: code.google.com/p/fullcalendar/issues/detail?id=1326 [1700]: code.google.com/p/fullcalendar/issues/detail?id=1700 [1992]: code.google.com/p/fullcalendar/issues/detail?id=1992 [1996]: code.google.com/p/fullcalendar/issues/detail?id=1996 [2017]: code.google.com/p/fullcalendar/issues/detail?id=2017 [2078]: code.google.com/p/fullcalendar/issues/detail?id=2078 [2132]: code.google.com/p/fullcalendar/issues/detail?id=2132 [2151]: code.google.com/p/fullcalendar/issues/detail?id=2151 [2169]: code.google.com/p/fullcalendar/issues/detail?id=2169 [2172]: code.google.com/p/fullcalendar/issues/detail?id=2172 [2186]: code.google.com/p/fullcalendar/issues/detail?id=2186 [2196]: code.google.com/p/fullcalendar/issues/detail?id=2196 [111]: code.google.com/p/fullcalendar/issues/detail?id=111
v2.0.3 (2014-08-15)
-
moment-2.8.1 compatibility ([2221])
-
relative path in bower.json ([PR 117])
-
upgraded jquery-ui and misc dev dependencies
[2221]: code.google.com/p/fullcalendar/issues/detail?id=2221 [PR 117]: github.com/arshaw/fullcalendar/pull/177
v2.0.2 (2014-06-24)
-
bug with persisting addEventSource calls ([2191])
-
bug with persisting removeEvents calls with an array source ([2187])
-
bug with removeEvents method when called with 0 removes all events ([2082])
[2191]: code.google.com/p/fullcalendar/issues/detail?id=2191 [2187]: code.google.com/p/fullcalendar/issues/detail?id=2187 [2082]: code.google.com/p/fullcalendar/issues/detail?id=2082
v2.0.1 (2014-06-15)
-
`delta` parameters reintroduced in `eventDrop` and `eventResize` handlers ([2156])
-
*Note*: this changes the argument order for `revertFunc`
-
-
wrongfully triggering a windowResize when resizing an agenda view event ([1116])
-
`this` values in event drag-n-drop/resize handlers consistently the DOM node ([1177])
-
`displayEventEnd` - v2 workaround to force display of an end time ([2090])
-
don't modify passed-in eventSource items ([954])
-
destroy method now removes fc-ltr class ([2033])
-
weeks of last/next month still visible when weekends are hidden ([2095])
-
fixed memory leak when destroying calendar with selectable/droppable ([2137])
-
Icelandic language ([2180])
-
Bahasa Indonesia language ([PR 172])
[1116]: code.google.com/p/fullcalendar/issues/detail?id=1116 [1177]: code.google.com/p/fullcalendar/issues/detail?id=1177 [2090]: code.google.com/p/fullcalendar/issues/detail?id=2090 [954]: code.google.com/p/fullcalendar/issues/detail?id=954 [2033]: code.google.com/p/fullcalendar/issues/detail?id=2033 [2095]: code.google.com/p/fullcalendar/issues/detail?id=2095 [2137]: code.google.com/p/fullcalendar/issues/detail?id=2137 [2156]: code.google.com/p/fullcalendar/issues/detail?id=2156 [2180]: code.google.com/p/fullcalendar/issues/detail?id=2180 [PR 172]: github.com/arshaw/fullcalendar/pull/172
v2.0.0 (2014-06-01)
Internationalization support, timezone support, and [MomentJS] integration. Extensive changes, many of which are backwards incompatible.
- Full list of changes][Upgrading-to-v2
-
| [Affected Issues]
An automated testing framework has been set up ([Karma] + [Jasmine]) and tests have been written which cover about half of FullCalendar's functionality. Special thanks to @incre-d, @vidbina, and @sirrocco for the help.
In addition, the main development repo has been repurposed to also include the built distributable JS/CSS for the project and will serve as the new [Bower] endpoint.
[MomentJS]: momentjs.com/ [Upgrading-to-v2]: arshaw.com/fullcalendar/wiki/Upgrading-to-v2/ [Date-Milestone]: code.google.com/p/fullcalendar/issues/list?can=1&q=milestone%3Ddate [Karma]: karma-runner.github.io/ [Jasmine]: jasmine.github.io/ [Bower]: bower.io/
v1.6.4 (2013-09-01)
-
better algorithm for positioning timed agenda events ([1115])
-
`slotEventOverlap` option to tweak timed agenda event overlapping ([218])
-
selection bug when slot height is customized ([1035])
-
supply view argument in `loading` callback ([1018])
-
fixed week number not displaying in agenda views ([1951])
-
fixed fullCalendar not initializing with no options ([1356])
-
NPM's `package.json`, no more warnings or errors ([1762])
-
building the bower component should output `bower.json` instead of `component.json` ([PR 125])
-
use bower internally for fetching new versions of jQuery and jQuery UI
[1115]: code.google.com/p/fullcalendar/issues/detail?id=1115 [218]: code.google.com/p/fullcalendar/issues/detail?id=218 [1035]: code.google.com/p/fullcalendar/issues/detail?id=1035 [1018]: code.google.com/p/fullcalendar/issues/detail?id=1018 [1951]: code.google.com/p/fullcalendar/issues/detail?id=1951 [1356]: code.google.com/p/fullcalendar/issues/detail?id=1356 [1762]: code.google.com/p/fullcalendar/issues/detail?id=1762 [PR 125]: github.com/arshaw/fullcalendar/pull/125
v1.6.3 (2013-08-10)
-
`viewRender` callback ([PR 15])
-
`viewDestroy` callback ([PR 15])
-
`eventDestroy` callback ([PR 111])
-
`handleWindowResize` option ([PR 54])
-
`eventStartEditable`/`startEditable` options ([PR 49])
-
`eventDurationEditable`/`durationEditable` options ([PR 49])
-
specify function for `$.ajax` `data` parameter for JSON event sources ([PR 59])
-
fixed bug with agenda event dropping in wrong column ([PR 55])
-
easier event element z-index customization ([PR 58])
-
classNames on past/future days ([PR 88])
-
allow `null`/`undefined` event titles ([PR 84])
-
small optimize for agenda event rendering ([PR 56])
-
deprecated:
- `viewDisplay` - `disableDragging` - `disableResizing`
-
bundled with latest jQuery (1.10.2) and jQuery UI (1.10.3)
[PR 15]: github.com/arshaw/fullcalendar/pull/15 [PR 111]: github.com/arshaw/fullcalendar/pull/111 [PR 54]: github.com/arshaw/fullcalendar/pull/54 [PR 49]: github.com/arshaw/fullcalendar/pull/49 [PR 59]: github.com/arshaw/fullcalendar/pull/59 [PR 55]: github.com/arshaw/fullcalendar/pull/55 [PR 58]: github.com/arshaw/fullcalendar/pull/58 [PR 88]: github.com/arshaw/fullcalendar/pull/88 [PR 84]: github.com/arshaw/fullcalendar/pull/84 [PR 56]: github.com/arshaw/fullcalendar/pull/56
v1.6.2 (2013-07-18)
-
`hiddenDays` option ([686])
-
bugfix: when `eventRender` returns `false`, incorrect stacking of events ([762])
-
bugfix: couldn't change `event.backgroundImage` when calling `updateEvent` (thx @stephenharris)
[686]: code.google.com/p/fullcalendar/issues/detail?id=686 [762]: code.google.com/p/fullcalendar/issues/detail?id=762
v1.6.1 (2013-04-14)
-
fixed event inner content overflow bug ([1783])
-
fixed table header className bug [1772]
-
removed text-shadow on events (better for general use, thx @tkrotoff)
[1783]: code.google.com/p/fullcalendar/issues/detail?id=1783 [1772]: code.google.com/p/fullcalendar/issues/detail?id=1772
v1.6.0 (2013-03-18)
-
visual facelift, with bootstrap-inspired buttons and colors
-
simplified HTML/CSS for events and buttons
-
`dayRender`, for modifying a day cell ([191], thx @althaus)
-
week numbers on side of calendar ([295])
- `weekNumber` - `weekNumberCalculation` - `weekNumberTitle` - `W` formatting variable
-
finer snapping granularity for agenda view events ([495], thx @ms-doodle-com)
-
`eventAfterAllRender` ([753], thx @pdrakeweb)
-
`eventDataTransform` (thx @joeyspo)
-
`data-date` attributes on cells (thx @Jae)
-
expose `$.fullCalendar.dateFormatters`
-
when clicking fast on buttons, prevent text selection
-
bundled with latest jQuery (1.9.1) and jQuery UI (1.10.2)
-
Grunt/Lumbar build system for internal development
-
build for Bower package manager
-
build for jQuery plugin site
[191]: code.google.com/p/fullcalendar/issues/detail?id=191 [295]: code.google.com/p/fullcalendar/issues/detail?id=295 [495]: code.google.com/p/fullcalendar/issues/detail?id=495 [753]: code.google.com/p/fullcalendar/issues/detail?id=753
v1.5.4 (2012-09-05)
-
made compatible with jQuery 1.8.* (thx @archaeron)
-
bundled with jQuery 1.8.1 and jQuery UI 1.8.23
v1.5.3 (2012-02-06)
-
fixed dragging issue with jQuery UI 1.8.16 ([1168])
-
bundled with jQuery 1.7.1 and jQuery UI 1.8.17
[1168]: code.google.com/p/fullcalendar/issues/detail?id=1168
v1.5.2 (2011-08-21)
-
correctly process UTC “Z” ISO8601 date strings ([750])
[750]: code.google.com/p/fullcalendar/issues/detail?id=750
v1.5.1 (2011-04-09)
-
more flexible ISO8601 date parsing ([814])
-
more flexible parsing of UNIX timestamps ([826])
-
FullCalendar now buildable from source on a Mac ([795])
-
FullCalendar QA'd in FF4 ([883])
-
upgraded to jQuery 1.5.2 (which supports IE9) and jQuery UI 1.8.11
[814]: code.google.com/p/fullcalendar/issues/detail?id=814 [826]: code.google.com/p/fullcalendar/issues/detail?id=826 [795]: code.google.com/p/fullcalendar/issues/detail?id=795 [883]: code.google.com/p/fullcalendar/issues/detail?id=883
v1.5 (2011-03-19)
-
slicker default styling for buttons
-
reworked a lot of the calendar's HTML and accompanying CSS (solves [327] and [395])
-
more printer-friendly (fullcalendar-print.css)
-
fullcalendar now inherits styles from jquery-ui themes differently. styles for buttons are distinct from styles for calendar cells. (solves [299])
-
can now color events through FullCalendar options and Event-Object properties ([117]) THIS IS NOW THE PREFERRED METHOD OF COLORING EVENTS (as opposed to using className and CSS)
- FullCalendar options: - eventColor (changes both background and border) - eventBackgroundColor - eventBorderColor - eventTextColor - Event-Object options: - color (changes both background and border) - backgroundColor - borderColor - textColor
-
can now specify an event source as an object with a `url` property (json feed) or an `events` property (function or array) with additional properties that will be applied to the entire event source:
- color (changes both background and border) - backgroudColor - borderColor - textColor - className - editable - allDayDefault - ignoreTimezone - startParam (for a feed) - endParam (for a feed) - ANY OF THE JQUERY $.ajax OPTIONS allows for easily changing from GET to POST and sending additional parameters ([386]) allows for easily attaching ajax handlers such as `error` ([754]) allows for turning caching on ([355])
-
Google Calendar feeds are now specified differently:
- specify a simple string of your feed's URL - specify an *object* with a `url` property of your feed's URL. you can include any of the new Event-Source options in this object. - the old `$.fullCalendar.gcalFeed` method still works
-
no more IE7 SSL popup ([504])
-
remove `cacheParam` - use json event source `cache` option instead
-
latest jquery/jquery-ui
[327]: code.google.com/p/fullcalendar/issues/detail?id=327 [395]: code.google.com/p/fullcalendar/issues/detail?id=395 [299]: code.google.com/p/fullcalendar/issues/detail?id=299 [117]: code.google.com/p/fullcalendar/issues/detail?id=117 [386]: code.google.com/p/fullcalendar/issues/detail?id=386 [754]: code.google.com/p/fullcalendar/issues/detail?id=754 [355]: code.google.com/p/fullcalendar/issues/detail?id=355 [504]: code.google.com/p/fullcalendar/issues/detail?id=504
v1.4.11 (2011-02-22)
-
fixed rerenderEvents bug ([790])
-
fixed bug with faulty dragging of events from all-day slot in agenda views
-
bundled with jquery 1.5 and jquery-ui 1.8.9
[790]: code.google.com/p/fullcalendar/issues/detail?id=790
v1.4.10 (2011-01-02)
-
fixed bug with resizing event to different week in 5-day month view ([740])
-
fixed bug with events not sticking after a removeEvents call ([757])
-
fixed bug with underlying parseTime method, and other uses of parseInt ([688])
[740]: code.google.com/p/fullcalendar/issues/detail?id=740 [757]: code.google.com/p/fullcalendar/issues/detail?id=757 [688]: code.google.com/p/fullcalendar/issues/detail?id=688
v1.4.9 (2010-11-16)
-
new algorithm for vertically stacking events ([111])
-
resizing an event to a different week ([306])
-
bug: some events not rendered with consecutive calls to addEventSource ([679])
[111]: code.google.com/p/fullcalendar/issues/detail?id=111 [306]: code.google.com/p/fullcalendar/issues/detail?id=306 [679]: code.google.com/p/fullcalendar/issues/detail?id=679
v1.4.8 (2010-10-16)
-
ignoreTimezone option (set to `false` to process UTC offsets in ISO8601 dates)
-
bugfixes
- event refetching not being called under certain conditions ([417], [554]) - event refetching being called multiple times under certain conditions ([586], [616]) - selection cannot be triggered by right mouse button ([558]) - agenda view left axis sized incorrectly ([465]) - IE js error when calendar is too narrow ([517]) - agenda view looks strange when no scrollbars ([235]) - improved parsing of ISO8601 dates with UTC offsets
-
$.fullCalendar.version
-
an internal refactor of the code, for easier future development and modularity
[417]: code.google.com/p/fullcalendar/issues/detail?id=417 [554]: code.google.com/p/fullcalendar/issues/detail?id=554 [586]: code.google.com/p/fullcalendar/issues/detail?id=586 [616]: code.google.com/p/fullcalendar/issues/detail?id=616 [558]: code.google.com/p/fullcalendar/issues/detail?id=558 [465]: code.google.com/p/fullcalendar/issues/detail?id=465 [517]: code.google.com/p/fullcalendar/issues/detail?id=517 [235]: code.google.com/p/fullcalendar/issues/detail?id=235
v1.4.7 (2010-07-05)
-
“dropping” external objects onto the calendar
- droppable (boolean, to turn on/off) - dropAccept (to filter which events the calendar will accept) - drop (trigger)
-
selectable options can now be specified with a View Option Hash
-
bugfixes
- dragged & reverted events having wrong time text ([406]) - bug rendering events that have an endtime with seconds, but no hours/minutes ([477]) - gotoDate date overflow bug ([429]) - wrong date reported when clicking on edge of last column in agenda views [412]
-
support newlines in event titles
-
select/unselect callbacks now passes native js event
[406]: code.google.com/p/fullcalendar/issues/detail?id=406 [477]: code.google.com/p/fullcalendar/issues/detail?id=477 [429]: code.google.com/p/fullcalendar/issues/detail?id=429 [412]: code.google.com/p/fullcalendar/issues/detail?id=412
v1.4.6 (2010-05-31)
-
“selecting” days or timeslots
- options: selectable, selectHelper, unselectAuto, unselectCancel - callbacks: select, unselect - methods: select, unselect
-
when dragging an event, the highlighting reflects the duration of the event
-
code compressing by Google Closure Compiler
-
bundled with jQuery 1.4.2 and jQuery UI 1.8.1
v1.4.5 (2010-02-21)
-
lazyFetching option, which can force the calendar to fetch events on every view/date change
-
scroll state of agenda views are preserved when switching back to view
-
bugfixes
- calling methods on an uninitialized fullcalendar throws error - IE6/7 bug where an entire view becomes invisible ([320]) - error when rendering a hidden calendar (in jquery ui tabs for example) in IE ([340]) - interconnected bugs related to calendar resizing and scrollbars - when switching views or clicking prev/next, calendar would "blink" ([333]) - liquid-width calendar's events shifted (depending on initial height of browser) ([341]) - more robust underlying algorithm for calendar resizing
[320]: code.google.com/p/fullcalendar/issues/detail?id=320 [340]: code.google.com/p/fullcalendar/issues/detail?id=340 [333]: code.google.com/p/fullcalendar/issues/detail?id=333 [341]: code.google.com/p/fullcalendar/issues/detail?id=341
v1.4.4 (2010-02-03)
-
optimized event rendering in all views (events render in 1/10 the time)
-
gotoDate() does not force the calendar to unnecessarily rerender
-
render() method now correctly readjusts height
v1.4.3 (2009-12-22)
-
added destroy method
-
Google Calendar event pages respect currentTimezone
-
caching now handled by jQuery's ajax
-
protection from setting aspectRatio to zero
-
bugfixes
- parseISO8601 and DST caused certain events to display day before - button positioning problem in IE6 - ajax event source removed after recently being added, events still displayed - event not displayed when end is an empty string - dynamically setting calendar height when no events have been fetched, throws error
v1.4.2 (2009-12-02)
-
eventAfterRender trigger
-
getDate & getView methods
-
height & contentHeight options (explicitly sets the pixel height)
-
minTime & maxTime options (restricts shown hours in agenda view)
-
getters [for all options] and setters [for height, contentHeight, and aspectRatio ONLY! stay tuned..]
-
render method now readjusts calendar's size
-
bugfixes
- lightbox scripts that use iframes (like fancybox) - day-of-week classNames were off when firstDay=1 - guaranteed space on right side of agenda events (even when stacked) - accepts ISO8601 dates with a space (instead of 'T')
v1.4.1 (2009-10-31)
-
can exclude weekends with new 'weekends' option
-
gcal feed 'currentTimezone' option
-
bugfixes
- year/month/date option sometimes wouldn't set correctly (depending on current date) - daylight savings issue caused agenda views to start at 1am (for BST users)
-
cleanup of gcal.js code
v1.4 (2009-10-19)
-
agendaWeek and agendaDay views
-
added some options for agenda views:
- allDaySlot - allDayText - firstHour - slotMinutes - defaultEventMinutes - axisFormat
-
modified some existing options/triggers to work with agenda views:
- dragOpacity and timeFormat can now accept a "View Hash" (a new concept) - dayClick now has an allDay parameter - eventDrop now has an an allDay parameter (this will affect those who use revertFunc, adjust parameter list)
-
added 'prevYear' and 'nextYear' for buttons in header
-
minor change for theme users, ui-state-hover not applied to active/inactive buttons
-
added event-color-changing example in docs
-
better defaults for right-to-left themed button icons
v1.3.2 (2009-10-13)
-
Bugfixes (please upgrade from 1.3.1!)
- squashed potential infinite loop when addMonths and addDays is called with an invalid date - $.fullCalendar.parseDate() now correctly parses IETF format - when switching views, the 'today' button sticks inactive, fixed
-
gotoDate now can accept a single Date argument
-
documentation for changes in 1.3.1 and 1.3.2 now on website
v1.3.1 (2009-09-30)
-
Important Bugfixes (please upgrade from 1.3!)
- When current date was late in the month, for long months, and prev/next buttons were clicked in month-view, some months would be skipped/repeated - In certain time zones, daylight savings time would cause certain days to be misnumbered in month-view
-
Subtle change in way week interval is chosen when switching from month to basicWeek/basicDay view
-
Added 'allDayDefault' option
-
Added 'changeView' and 'render' methods
v1.3 (2009-09-21)
-
different 'views': month/basicWeek/basicDay
-
more flexible 'header' system for buttons
-
themable by jQuery UI themes
-
resizable events (require jQuery UI resizable plugin)
-
rescoped & rewritten CSS, enhanced default look
-
cleaner css & rendering techniques for right-to-left
-
reworked options & API to support multiple views / be consistent with jQuery UI
-
refactoring of entire codebase
- broken into different JS & CSS files, assembled w/ build scripts - new test suite for new features, uses firebug-lite
-
refactored docs
-
Options
- + date - + defaultView - + aspectRatio - + disableResizing - + monthNames (use instead of $.fullCalendar.monthNames) - + monthNamesShort (use instead of $.fullCalendar.monthAbbrevs) - + dayNames (use instead of $.fullCalendar.dayNames) - + dayNamesShort (use instead of $.fullCalendar.dayAbbrevs) - + theme - + buttonText - + buttonIcons - x draggable -> editable/disableDragging - x fixedWeeks -> weekMode - x abbrevDayHeadings -> columnFormat - x buttons/title -> header - x eventDragOpacity -> dragOpacity - x eventRevertDuration -> dragRevertDuration - x weekStart -> firstDay - x rightToLeft -> isRTL - x showTime (use 'allDay' CalEvent property instead)
-
Triggered Actions
- + eventResizeStart - + eventResizeStop - + eventResize - x monthDisplay -> viewDisplay - x resize -> windowResize - 'eventDrop' params changed, can revert if ajax cuts out
-
CalEvent Properties
- x showTime -> allDay - x draggable -> editable - 'end' is now INCLUSIVE when allDay=true - 'url' now produces a real <a> tag, more native clicking/tab behavior
-
Methods:
- + renderEvent - x prevMonth -> prev - x nextMonth -> next - x prevYear/nextYear -> moveDate - x refresh -> rerenderEvents/refetchEvents - x removeEvent -> removeEvents - x getEventsByID -> clientEvents
-
Utilities:
- 'formatDate' format string completely changed (inspired by jQuery UI datepicker + datejs) - 'formatDates' added to support date-ranges
-
Google Calendar Options:
- x draggable -> editable
-
Bugfixes
- gcal extension fetched 25 results max, now fetches all
v1.2.1 (2009-06-29)
-
bugfixes
- allows and corrects invalid end dates for events - doesn't throw an error in IE while rendering when display:none - fixed 'loading' callback when used w/ multiple addEventSource calls - gcal className can now be an array
v1.2 (2009-05-31)
-
expanded API
- 'className' CalEvent attribute - 'source' CalEvent attribute - dynamically get/add/remove/update events of current month - locale improvements: change month/day name text - better date formatting ($.fullCalendar.formatDate) - multiple 'event sources' allowed - dynamically add/remove event sources
-
options for prevYear and nextYear buttons
-
docs have been reworked (include addition of Google Calendar docs)
-
changed behavior of parseDate for number strings (now interpets as unix timestamp, not MS times)
-
bugfixes
- rightToLeft month start bug - off-by-one errors with month formatting commands - events from previous months sticking when clicking prev/next quickly
-
Google Calendar API changed to work w/ multiple event sources
- can also provide 'className' and 'draggable' options
-
date utilties moved from $ to $.fullCalendar
-
more documentation in source code
-
minified version of fullcalendar.js
-
test suit (available from svn)
-
top buttons now use `<button>` w/ an inner `<span>` for better css cusomization
- thus CSS has changed. IF UPGRADING FROM PREVIOUS VERSIONS, UPGRADE YOUR FULLCALENDAR.CSS FILE
v1.1 (2009-05-10)
-
Added the following options:
- weekStart - rightToLeft - titleFormat - timeFormat - cacheParam - resize
-
Fixed rendering bugs
- Opera 9.25 (events placement & window resizing) - IE6 (window resizing)
-
Optimized window resizing for ALL browsers
-
Events on same day now sorted by start time (but first by timespan)
-
Correct z-index when dragging
-
Dragging contained in overflow DIV for IE6
-
Modified fullcalendar.css
- for right-to-left support - for variable start-of-week - for IE6 resizing bug - for THEAD and TBODY (in 1.0, just used TBODY, restructured in 1.1) - IF UPGRADING FROM FULLCALENDAR 1.0, YOU MUST UPGRADE FULLCALENDAR.CSS


Why do people seem to think that the GIL (global interpreter lock) is such a big deal?
Are there more people out there than I realize who have applications that fall in that multi-processor sweet spot? You need:
Does Python scale wonderfully to multiple processes? It's no Erlang, and concurrency oriented programming is not Python's strong point (not necessarily a weak point -- let's just say it's not a point either way). But to me that's more of a programming tool issue, not an interpreter issue. POSH matters more than the GIL, and I'm sure there's other ideas and programming techniques which could matter even more than that. So let's just forget about the GIL, there's far more interesting things to be concerned with.
I can't tick off every item in your checklist, and maybe there's a way around it, but the GIL does seem to get in the way of taking our work on SCons to the next level of optimization.
We have a pretty good thread-pool architecture for controlling builds, courtesy fine work by Anthony Roach and J.T. Conklin, and it works great for the actual build portion: we start a pool with N threads, each thread requests work from the central dependency tree as needed and controls what it kicks off.
We'd like to be able to use the same model for doing the dependency analysis that creates the tree, which is largely regular expression searches on the contents of source code files. Because we're using Python code to do that dependency analysis, we can't use the same model that serves us so well for controlling the build portion.
On a big multi-processor dedicated build server, where we could really use all the horsepower, during dependency analysis you can see all of the threads and processors go silent except for one at a time, which gets the GIL and calculates the dependencies. I'm told that the GIL is the (or a) big stumbling block here--I'm not the threading guru on our project--but if it's really not a big deal and there's some other way we could structure things to make use of the other processors, I'd love to hear about it...
While it's probably a little annoying, it seems straight-forward enough to deal with: fork instead of using threads. You'll have to pre-partition the workload, or use some sort of multi-process queue (a database can be an easy way to do this communication, though I'm sure there are other good techniques). Results can be passed back on a socket, via shared memory (maybe POSH), or through files. Maybe use Pyro or Twisted Broker. If you don't use shared memory then you can probably scale this to separate machines fairly easily.
If I was implementing it I'd probably use Pyro, exposing some manager object that handed out jobs and collected results. Then you just need some process manager that can spawn new processes and set them on task (bonus points if it can spawn processes on other machines).# Ian Bicking
Sorry, forking is only available on UNIX; we're really looking for a cross-platform solution. Threading would provide exactly the right cross-platform model for this if it weren't for the GIL.
I was pondering my previous reply (after saving it, of course) and thinking that in my haste to respond to the fork suggestion, I might have started this thread down a path I didn't intend.
First, I'm not looking for you or anyone else to solve this particular issue for us. We've spent a lot of time looking at a lot of possible solutions, and unfortunately, this particular problem is one that does not lend itself to refactoring into separate process. (The cross-platform issue I mentioned is one reason, but there are also performance issues with fork()ing large memory images that chew up the anticipated benefit from calculating dependencies in parallel.)
Second, I'm much more in the middle of the larger GIL issue than my previous two replies might imply. I'm perfectly willing to believe that the GIL brings with it implementation efficiencies, and that if Python threads were to be re-architected without a GIL, we might pay for it in slower performance in other areas. So overall, the GIL is what it is, and simply has to be accounted for or programmed around. To that extent, I agree with your sentiment that people who cast it as the root of all evil are probably inflating the problem.
That having been said, it would be really handy in our case to not have to program around the GIL, because our architecture already provides a huge, proven performance boost except when we want to do multiple things in Python. Can we program around that? Sure, probably. And we'll have to, if we want to speed up this part of SCons. But that doesn't change the fact that if I could wave a magic wand and create a Python without a GIL (and assume no side effects from that change), we'd get a huge performance win, with virtually no programming effort at all.
So the larger point I want to make here is simply that the fact that you personally haven't run into the situations described in your criteria doesn't mean that there aren't compelling, real-world counter-examples to your assertion that the GIL is only a problem in "one little corner case, boo hoo." Of course, you're free to decide that this is just an example of your "corner case," but I can tell you that we have a significant and growing user community that would benefit hugely if we can speed up our dependency analysis, and that at a minimum the presence of the GIL means that it'll be more work than I'd like it to be...
In any event, thanks for a thought-provoking blog entry.
The GIL is a problem for exactly two (real) reasons:
1) Some external system mandates the use of threads. This can be the operating system which requires threads for certain types of I/O. Or it can be other applications that are naturally multi-threaded, and want Python to work seamlessly without clear thead-locality of data.
2) The other group is populated by people who need threads because they do not understand state-machines. So threads become the one-stop-shop for all forms of programmatic concurrency, without regard for the overhead they involve.
If I am right in my thinking, this refutes the argument that the GIL is only a concern for those with multiprocessor systems. Of course the MP argument is raised all of the time, but only because it is easy to spout on about requirements instead of features.
Kevin: I don't see how state machines will help. Without threads the GIL doesn't matter, but you'll still be wasting that second processor. Removing the GIL is about making threads utilize the second processor, where the only other way is to use multiple processes.
Steven: I don't really know what your data set looks like -- if there's a large piece of data that your worker threads/processes need access to, then I imagine it could be a problem. But I'd expect there isn't a big data set, you simply need the worker threads/processes to search for dependencies, which you do by searching for specific patterns. The actual communication of data isn't too great -- filenames for the workers to process, returning lists of files they depend on.
And even if you can't use fork, you can still spawn new processes (if not as quickly). Like a thread pool, you then use a process pool, where worker processes wait around for something to do. If you have a persistent server of some sort, this shouldn't be a problem.
But the problem persists if you want the entire process to start up quickly. Python isn't a quick startup, and the harder you work the longer it takes -- building up process pools and the like only make it worse. And since you're probably concerned about latency, not throughput, to a degree this may describe SCons'... anyway, I suppose my boo hoo comment was a little callous ;) But there's always a clever solution, and it's easier to implement those solutions in Python than in the interpreter (and probably every C extension for Python).# Ian Bicking
Ian, I contend that the GIL issue has nothing to do with a second, third, or tenth processor. Anyone who claims otherwise isn't serious about high-performance computing.
Let's face it -- there is enough innate parallelism is virtually all common computing tasks that there is no reason why we should accept the overhead of a freely threaded interpreter, just to be able to perform ad-hoc task partitioning. It is a lose-lose solution -- you lose in the single-threaded case because everything is much slower, and you lose in the multi-threaded (multi-processor) case because of the unnecessary complexity introduced by sharing the same address space.
So it does all come down to state machines -- if one understands that a multi-threaded program is just an abstraction of a state-machine, and that many better and more efficient relizations of that same state-machine are possible, then people would stop trying to use threads in places where they are not the best solution.
Interesting blog!
In my experience SMP is something that people need when they really need it. And for those who really need it, GIL is a problem. :-)
It's also important to realize that although MP machines are rare now, multithreading processors (like the latest Pentium 4) are becoming more and more prevalent. Thread switching is seen as the easiest way to keep the processor fed, and taking advantage of it will be more and more important as time goes on. It seems like every processor company has a multithreading or mp processor coming out in the future, and I'd hate to see python lose out on that wave. And since it seems like half of tech success is marketing, just losing the marketing point could be a loss. I'd love to see Python succeed everywhere in the future, but I'm a little worried.# Corey Coughlin
Kevin-- Re: your comment:
So it does all come down to state machines -- if one understands that a multi-threaded program is just an abstraction of a state-machine, and that many better and more efficient relizations of that same state-machine are possible, then people would stop trying to use threads in places where they are not the best solution.
Can you point those of us who aren't concurrency/thread gurus to resources that would help get a grasp on the issues involved, and figure out how we might break down a threaded abstraction into a more efficient state machine?
I couldn't agree with Corey more. Muthithreaded processors or multiprocessors on a chip will become common place soon. I love Python but I am also worried that many Python developers do not seem to care about this problem.
MP machines are not rare in corporate projects -- it has been many, many years that I've worked on a project that didn't run on MP servers.
One of the big reasons that decision makers like Java is that it is true that a little extra money can boost performance of a well-threaded program. Whether you agree or not, this is what is commonly believed and past experience does seem to bear this out for me.
Also note that it is usually easier to design failsafe features into a monolithic program than a grid design. Most of the problems I encounter on my current project are due to failure handling between the multiple applications (~7 programs for one "app"). We have one large open source project saying threads are for weenies (Python, GVR) and another saying monolithic is the only way to go (Linux kernel, LT). Discounting the performance argument, what other design arguments have been made in favor of the Linux kernel over Minix, etc.
Jython, however, was used in one project to great success, but there is a feeling among management that it is not a "real" project and it may fall by the wayside.
>And I haven't actually heard anyone >say, "Python is great, but that GIL >really kicked my ass when I was working >on a past project."
Of course not, because they didn't consider using Python in the first place because of the GIL limitation.# Anonymous Coward
Even if the GIL is not a big deal in many cases, it remains a factor worth considering in designing and deploying applications. If I were running a single instance of a multithreaded application on an SMP box and had limited hardware resources, I'd want to be aware that one CPU would be underutilized and think about what else I should run on it, too. And if I were writing a Python application to run on a mosix cluster, the GIL would force me away from a threaded architecture, because Python threads won't migrate. But the fact that the GIL matters in some situations doesn't mean that Python sucks, or that applications that don't scale to SMP suck. It isn't unheard of for OSes -- damned good OSes, like Linux -- to have difficulty with SMP, too.# Jacob Smullyan
I take issue with the "it doesn't matter to me, therefore it isn't important" attitude of the original post, that smacks of denial. If I had to make a list of things I would like fixed in Python, the GIL would top that list. Sure, it can be worked around. But the fact that there are work-arounds does not make it any less a wart on an otherwise fine language. On some platforms, notably Win32, multiple processes incur a significantly higher overhead than threading, and pushing towards multiprocessing reduces overall system capacity, and the GIL acts as a kind of glass ceiling on performance.
 Multi-threading a single process is the way the standard works. There are many applications that maintain caches, and splitting them into multiple processes loses cache hit ratios. We also have to maintain multiple Corba connection pools, which reduces efficiency over a single pool due to queueing theory effects. Sure, the caches can be maintained in shared memory, but I don't think anybody can maintain with a straight face Python handles objects in shared memory particularly elegantly or well.
Finally, multiprocessors are far from exotic, and with hyperthreading, they are actually becoming the rule rather than the exception.
An example of where the GIL gets in Python's way:FWIW, you can resolve many of the performance issues you are running into with your partitioned workload by assigning work to idle engines in LIFO order. This will ensure that the idle engines at the most common workload levels end up paged out, and not detracting from the processes which you are actually keeping loaded.
This technique is called "hot engine scheduling".
--Terry
# Terry Lambert
In the finance world, companies need to tie their systems into news/data feeds. And I'm not talking just one feed. More like 20-50 different feeds, all with differing formats (various dialects of FIX, etc). Python is nearly ideal for this application: you can build a nice OO framework, but also hack in little ad-hoc chunks as necessary.
Python could *own* this space, save for two little problems.
Problem #1: those 20-50 feeds flow continuously. Traffic is very bursty, and often you have only a small window of time to process a given message.
Problem #2: finance companies are not very tolerant of application failure. Apps & servers need to be (triply) overbuilt to withstand Murphy's Law.
SMP hardware is cheap insurance for those days when messages get delayed upstream for hours on end, then come blasting down the pipe right before market close. And you do want that insurance, or you will be out of a job when Murphy strikes.
It's all about providing a palette of options for scaling. If you need to scale up, you typically need to do it pronto. And if you need to completely re-architect your application, you're out of the game.
FYI, I know a company that was using CPython for exactly this application. They have since switched to a Java core for the app plus JPython for scripting, specifically to get away from the GIL.
I have a little image processing app. It wants to display the processed version of a group of images. I have had to bend over backwards in the worst way in order to allow it to do the image transformations in the background and still get reasonable performance. Even after all my machinations it is still performing at 25% of what it's ideal performance would be. It's not that any of this is impossible to surmount but that it takes so much work to go past the "toy" stage to the "tool" stage for any processor intensive GUI app.
I've done enough threaded C++ code in my life to know that it's not trivial to make this fit into a powerful, late-binding language. Certainly there are no other equivalently powerful languages with the sort of concurrency I would like (e.g. Lisp, Ruby, Perl, etc...). It seems like a problem that ought to be solveable eventually though, and I think it is quite important. The GIL has to go.
# Jeff
# John Costello
Argh.

Of course, if Python had a full-featured MPI implementation, this wouldn't be so much of a problem. I'm working on it!# John Costello
I'm a student at the College of Wooster in Ohio, and I'm having trouble with Python threading and MPI, as well. Specifically I'm using the Pypar MPI module, and when one of my threads blocks on a send/receive, my whole program blocks. I'm a Python beginner starting with this project, and needless to say, I was quite irritated when I discovered the all-important GIL and the role it plays. Does anyone have any good suggestions to overcome this limitation?
# Joel Wietelmann
I tried out the posh module, and have found that at least on Python 2.3.5, it's quite unreliable. For example, sharing an empty list or popping from a shared list results in segfaults. Has anyone been using posh extensibly with a recent version of Python?
Good. More spin surrounding the GIL. If there's one way to identify a serious design defect it's as simple as measuring how much after market documentation is devoted to explaining and justifying the issue. The GIL has got to be right up there with lamba and long fought battle to get the += operator.
So, now I've heard several tacks for discounting the seriousness of the GIL limitation.
- I don't has multiple processors because I'm too poor, boo hoo. :( Yes, hardware costs are dropping. But I'm getting poorer (cheaper) at an even faster rate. Snif!
- I tried thread programming once, ran into a deadlock (I think) and determined the problem could best be solved by demonizing all thread programming as unnecessary and EVIL. Whew!
- What's a GIL??
- I'd fix the GIL tomorrow but my ego says I'll get more credit if I code yet another GUI or web interface. Hmmm, or maybe a screen saver!
- If we allowed programmers around the GIL restrictions then there'd be no reason for Java to exist.
- If we fix the GIL then we'd have to admit it was a short sighted idea in the first place. After all of these years. While we harped about it's "importance".
- Tried to fix the GIL once. Can't be done. End of story.
- Cause Guido told me so.
Sigh.
# John Mudd
I don't care about the GIL because I care about real performance problems I encounter, and I have never, ever encountered a performance problem because of the GIL. It's a theoretical problem, not a real problem that programmers encounter, except in a very small number of cases for a very small number of programmers.
FYI: The May issue of Dr, Dobb's is available now. There's an article in it entitled "Multi-threaded Technology & Dual-Core Processors". Not sure if this is significant though. The author is an engineer at Intel, not exactly a mainstream company.
Oh, but it's not a total waste. The same issue contains another article "Python 2.4 Decorators". Now THAT's definitely not a case of a solution in search of a problem.
The GIL may not be the worst thing in the world but why are you defending it? It doesn't deserve it.
Ironically, the GIL is functionally almost equivalent to the Linux kernel's BKL (Big Kernel Lock). Now that it's virtually gone, no one would put it back right now. Few would claim that removing it was a bad idea. Speed gains were concrete. Considering that Python is anecdotally 30 times slower than straight C, if we can get a 10% speed increase, isn't that worthwhile?
I have had issues with the GIL in real projects. The most vexing was having my GUI fight with my XML processor over the GIL. Both shouldn't affect each other. It's not good, and it's not defensible. I ended up solving it by forking, but it generated over 400 lines of very touchy code that I have to maintain. Is it that unreasonable that I don't like Python getting in my way? That's why I use it in the first place.
Apart from my app, how many real projects need to put up a GUI and chew lots of XML? How about a web browser? Is that not a "real" project? I don't know what kind of projects you deal with on a daily basis. I do know that you are a proponent of WSGI. Can you really stand behind providing a world-class web standards kit that can't run in highly parallel applications? Isn't that what makes web-applications fly?
This is one of the major issues still remaining in Python.
While I'm at it, a lack of good memory management is another. I don't mean garbage collection SUX0RZ, I mean hogging megabytes of extra memory per process because Python doesn't like giving it back (and shared memory support too please). This is another problem that WSGI inadvertently addresses and that can complicate the "Use The Fork, Luke," suggestion above. It's difficult to run many Python processes on because they don't give memory back readily. Try cyclically generating a 250MB report once per day. You'll find that your server process will inflate and never deflate.
At any rate, having structure-granular ILs (or even memory-region-granular ILs) would be a godsend for some of us.
# Jayson Vantuyl
Returning memory to the OS during runtime is very rare among UNIX programs in general. I would support the creation of some function (perhaps in the sys module) that would cause Python to do this (perhaps sys.free()? or sys.sbrk(-1) or something like that).
However, the saner answer for a daemon process that's about to generate a 250MB report (or otherwise use a tremendous amount of memory) would be to fork(), generate the report, and exit(). The memory allocations will all happen in the child and it's memory will be freed back to the OS when the child process dies.
JimD
> The GIL may not be the worst thing in the world but why are you defending it?
It has a cost, but it also has benefits -- there are an awful lot of threading-related bugs that just don't happen because of the GIL. If the cost isn't so very high (and maybe even if it is), then that is a good tradeoff.
> Apart from my app, how many real projects need to put up a GUI and chew lots of XML?
If the XML is a chokepoint, it might be worth using an extension module -- which can release the GIL.
> This is one of the major issues still remaining in Python.
Brett Cannon's thesis will work on sandboxing, so that you can run multiple interpreters. Since they'll have separate object spaces, the GIL contention should be greatly reduced.
> hogging megabytes of extra memory per process because Python doesn't like giving it back
I believe 2.5 includes a patch to change this. I don't know whether or not it is the default.
# JimJJewett
.... why are you defending [the GIL]?
It has a cost, but it also has benefits -- there are an awful lot of threading-related bugs that just don't happen because of the GIL. If the cost isn't so very high (and maybe even if it is), then that is a good tradeoff.
.... many real projects need to put up a GUI and chew lots of XML
If the XML is a chokepoint, it might be worth using an extension module -- which can release the GIL.
Also note that Brett Cannon's thesis will work on sandboxing, so that you can run multiple interpreters. Since they'll have separate object spaces, the GIL contention should be greatly reduced.
... [and also] hogging megabytes of extra memory per process because Python doesn't like giving it back
I believe 2.5 includes a patch to change this. I don't know whether or not it is the default.
# JimJJewett
e2vesc4q-800229030# anonymous
Wouldn't it be possible to use an external threading library bypassing the GIL limitation?
# Marc
Read it and weep, GIL lovers.
Why Events Are A Bad Idea http://www.usenix.org/events/hotos03/tech/vonbehren.html
# John Mudd
Did you actually read that paper? The proposed alternative to events is a custom, user-space thread implementation with tight compiler integration. It has absolutely nothing whatsoever to do with the kind of threading supported in any mainstream language today.
I used to be a serious python 'head'.. (pythonista, whateva).. now I still appreciate python, but this 'defending the GIL' and 'just fork' business is a load of crap and continually makes me -not- want to use python, although I still find it's minimalism, clarity, and large availability of extensions wonderful.
first of all- as to the question of 'who needs threads' - I hope this is a joke.
If you need performance, which some people do, and threading helps them achieve performance and clear programming abstractions which it would, and it wouldn't hurt non-threading too much, which it wouldn't if designed properly, and these people would use your language and would remove barriers to people considering the languages seriously, then why would you -not- want it?
There are at least 2 interpreted (or should I say incrementally compiled) lisp/scheme interpreters that exist, for real, today.. chez scheme and SBCL on x86. And then of course, there is java's bytcoded VM which is threaded in some cases as well.. as far as I can remember perl threads are native as well (when they work).. and parrot definately has an interpreter framework for multithreading - if python ever moves in that direction instead of towards PyPy 'language feature obsession' like I hope it would.
R.Kent Dyvbig, the author of chez scheme has a wonderfully detailed paper (http://www.cs.indiana.edu/~dyb/pubs/hocs.pdf) about the development of chez scheme over the past 20+! years with plenty of technical details (conceptually anyway, it's still a closed-source scheme implementation) about VM and RTTI in dynamic languages. The section on the implementation of version 7 deals specifically with adding threading to the system - not trivial, but managable if you want to do it. This article took me many passes to even comprehend - so don't be afraid :)
As for the 'it might have a performance hit' or 'what about the broken extension modules' crowd, even if this were true (if designed properly, the performance hit could be designed around and would be minimal, and you could always lock around all entry to broken threaded modules) there's nothing saying that true threads could not be a compile-time option to building the interpreter with or without native threads for those that prefer the single threaded approach "with less overhead" (or even have it determined at start-up-time via some kind of system check)
Not to mention all the argument to the negative about MP locking in the FreeBSD world (that lead to Dfly breaking off) and as mentioned by this thread in the NPTL-implementing-Linux world - all of which states that 'locking with too much underneath the lock' is bad.
Big locks are bad long-term design decisions (e.g. it would be a hack for the case of broken modules as I mentioned it above), working around them is very difficult, but is not impossible, and defending bad design decisions is simply an excuse, not a reason.
For those that say 'just fork' I pose the simple question :
"If threads are unecessary when fork() exists, why were they invented for unix in the first place?"
which is a unix-specific argument, but its a good example where fork wasn't good enough and threading was added to overcome it's limitations. It doesn't necissarily answer the question of threading being
necessary, but noone is arguing that 'real threads' shouldn't exist in Unix or Unix-Like systemson this thread.. and probably wouldn't dare.
I do understand that a big locking strategy is often a good first step towards a better implementation, but sometimes it's time to take a -second- step.. (and a third, etc) to get an even better implementation.
And I don't want it bad enough to code it - even if that makes me a whiner.
# C Turner
There are ways to overcome GIL limitations in python.
One of them is to use ppsmp module: http://www.parallelpython.com
It allows to execute python code in parallel on SMP computers (both multicore and multiprocessor)
There are numerous applications that satisfy your criteria, you have just written them to sound daunting. Just about any image processing application (photoshop, gimp) or video or audio application is a candidate. If you don't have needs for real multi-threading, then lucky you, but many people do.
The GIL is a huge wart of the side of an otherwise attrective language.
This needs to be fixed for the language to be taken seriously. Otherwise Python will be consigned to the scrap heap of toy languages like Pascal. It's not even worth debating it. Don't rationalize this wart, think about how it could be fixed.
I came to love python and teach classes in it. Now, due to frustration over the GIL (i.e. the fact I could double or octuple) the speed of the compute-bound processing I do, I may switch back to C or Java for my own work.
To call this a "corner case" is just silly. The popularity of multi-core systems is not just for running multiple process. Multi-threading is often much easier to implement for a computationally intensive task.
# Greg


Instructions
Given a function that is handed an array of integers.
Your goal is to return an array, sorted ascending.
You have three minutes to complete this challenge.
Name:
Email:
Phone:


Sep 2022
Creating a Role in Postgres
Here's how to create a role that can log in, but don't give it a password:
CREATE ROLE nhatbui LOGIN;
And here is creating a role with a password that is valid until the end of 2022. After one second has ticked in 2023, the password is no longer valid:
CREATE USER nhatbui WITH PASSWORD 'st@bl3nhAt' VALID UNTIL '2023-01-01';
The syntax is fine. But what could possibly go wrong? Oh dear, your password will appear as plain text somewhere in the log file; it can be stolen in no easier way. To do it properly, we first create a role that can log in but don't give it a password:
CREATE ROLE nhatbui LOGIN;
Once the role nhatbui
is created, we can then give it a password with this command:
\password nhatbui
The terminal now will ask you to type in the new password. Just like other passwords, it will be hidden in the terminal. So just type without wondering. Here's what mine displays:
postgres=# \password nhatbui
Enter new password for user "nhatbui":
Enter it again:
As far as I am aware, Postgres will hash the password before storing it, unless the supplied string is already hashed. So you don't have to hash it.
Further reading
See all posts


A static inner class does not keep an implicit reference to its enclosing instance. This prevents a common cause of memory leaks and uses less memory per class instance.
The quick-fix extracts the anonymous class into a named static inner class.
Example:
void sample(){
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
}
});
}
After the quick-fix is applied:
void sample(){
Thread thread = new Thread(new Task());
}
private static class Task implements Runnable {
@Override
public void run() {
}
}


from ursina
import *
class Inventory(
Entity):
def __init__(self):
super().__init__()
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
app.run()
# text, size 1
# size 2, bold
2 Adding graphics
# size 1, normal
However,
if we run the code, we
'll see that there's nothing visible.
Let
's parent it to the ui and set the model to 'quad', an included model.
# code, size .8
from ursina
import *
class Inventory(
Entity):
def __init__(self):
super().__init__(
parent = camera.ui,
# +
model =
'quad' # +
)
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
app.run()
# text, size 1
If we look at it now, we see it's a white square in the middle of the screen.
Let's set it to a nicer shape. We also want (
0,
0) to be in the upper left corner
because it makes it easier to add items later. Let's also give it a texture and a color.
If we have both, the color value will tint the texture.
Now, this is nice and all, but wouldn't it be nice to show a grid as well?
There are multiple way to do that, but in this case, we'll simply make the texture repeat
by setting texture_scale to (
5,
6). That'll nicely fit the size of our inventory.
# code, size .8
from ursina
import *
class Inventory(
Entity):
def __init__(self):
super().__init__(
parent = camera.ui,
model =
'quad',
scale = (.
5, .
8),
# +
origin = (-.
5, .
5),
# +
position = (-.
3,.
4),
# +
texture =
'white_cube',
# +
texture_scale = (
5,
8),
# +
color = color.dark_gray
# +
)
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
app.run()
# text, size 1
# size 2, bold
3 Adding placeholder items
# size 1, normal
Let's try to add some items to the inventory.
# code, size .8
from ursina
import *
class Inventory(
Entity):
def __init__(self):
super().__init__(
parent = camera.ui,
model =
'quad',
scale = (.
5, .
8),
origin = (-.
5, .
5),
position = (-.
3,.
4),
texture =
'white_cube',
texture_scale = (
5,
8),
color = color.dark_gray
)
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
item = Button(
parent=inventory,
color=color.red,
position=(
0,
0))
# +
item = Button(
parent=inventory,
color=color.green,
position=(
2,
0))
# +
app.run()
# text, size 1
Well, that didn't go as planned. The items cover the entire inventory and
the second item is way off to the left.
Let's fix this by making another object to put the items under.
Scale the object to the size of an item.
They also don't fit the grid. Fix that by setting origin to the upper left
corner, (-.
5,.
5).
# code, size .8
from ursina
import *
class Inventory(
Entity):
def __init__(self):
super().__init__(
parent = camera.ui,
model =
'quad',
scale = (.
5, .
8),
origin = (-.
5, .
5),
position = (-.
3,.
4),
texture =
'white_cube',
texture_scale = (
5,
8),
color = color.dark_gray
)
self.item_parent =
Entity(
parent=self,
scale=(
1/
5,
1/
8))
# +
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
item = Button(
parent=inventory.item_parent,
origin=(-.
5,.
5),
color=color.red,
position=(
0,
0))
# +
item = Button(
parent=inventory.item_parent,
origin=(-.
5,.
5),
color=color.green,
position=(
2,
0))
# +
app.run()
# text, size 1
# size 2, bold
4 Adding items
# size 1, normal
We've added some items manually to make sure they get the right scale and position,
but we should make an append() function so it's easy to add items.
Let
's start by making a function called 'append()' and make it spawn an item
when we send it a string. We
'll also set the button's text to the string we
receive so we can differentiate them.
Let's give them a random color too, why not.
Lastly, let
's call inventory.append('test item') a couple of times to make sure it works.
# code, size .8
from ursina
import *
class Inventory(
Entity):
def __init__(self):
super().__init__(
parent = camera.ui,
model =
'quad',
scale = (.
5, .
8),
origin = (-.
5, .
5),
position = (-.
3,.
4),
texture =
'white_cube',
texture_scale = (
5,
8),
color = color.dark_gray
)
self.item_parent =
Entity(
parent=self,
scale=(
1/
5,
1/
8))
def append(self, item):
# +
Button(
# +
parent = inventory.item_parent,
# +
model =
'quad',
# +
origin = (-.
5,.
5),
# +
color = color.random_color(),
# +
z = -.
1 # +
)
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
inventory.append(
'test item')
# +
inventory.append(
'test item')
# +
app.run()
# text, size 1
# size 2, bold
5 Find a free slot in the inventory
# size 1, normal
The items gets added, but they overlap. We need to find the first open slot in the inventory
and place the item there. We can to this by checking each grid position and see
if any
if the items occupy that position already.
# code, size .8
from ursina
import *
class Inventory(
Entity):
def __init__(self):
super().__init__(
parent = camera.ui,
model =
'quad',
scale = (.
5, .
8),
origin = (-.
5, .
5),
position = (-.
3,.
4),
texture =
'white_cube',
texture_scale = (
5,
8),
color = color.dark_gray
)
self.item_parent =
Entity(
parent=self,
scale=(
1/
5,
1/
8))
def find_free_spot(self):
# +
taken_spots = [(int(e.x), int(e.y))
for e in self.item_parent.children]
# +
for y in
range(
8):
# +
for x in
range(
5):
# +
if not (x,-y) in taken_spots:
# +
return (x,-y)
# +
def append(self, item):
Button(
parent = inventory.item_parent,
model =
'quad',
origin = (-.
5,.
5),
color = color.random_color(),
position = self.find_free_spot(),
# +
z = -.
1
)
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
for i in
range(
7):
# +
inventory.append(
'test item')
# +
app.run()
# text, size 1
# size 2, bold
6 Add random item button
# size 1, normal
Make a button to add a random item to the inventory. This is
not part of the inventory itself,
but it's useful in order to test it.
Assign the button
's 'on_click' to a function, and it will call that function when we click it.
button.on_click = inventory
Let's make an tuple with those and make the button choose a random item
from the tuple
using random.choice(items)
# code, size .8
if __name__ ==
'__main__':
app = Ursina()
inventory = Inventory()
def add_item():
# +
inventory.append(random.choice((
'bag',
'bow_arrow',
'gem',
'orb',
'sword')))
# +
for i in
range(
7):
# +
add_item()
# +
add_item_button = Button(
# +
scale = (.
1,.
1),
# +
x = -.
5,
# +
color = color.lime.tint(-.
25),
# +
text =
'+',
# +
tooltip = Tooltip(
'Add random item'),
# +
on_click = add_item
# +
)
# +
app.run()
# text, size 1
# size 2, bold
7 Adding textures and hover text
# size 1, normal
To add textures, just set
texture=item and it will try to find a
texture with that name. It searches first in the project's assets and then
in the assets included with ursina. I've included some icons
for the purpose
if this tutorial, but feel free to add your own.
Let
's also remove the random color and instead show the item's name when we hover it with the mouse.
If a button has
'tooltip' set to something, it will show it when we hover the Button.
# code, size .8
def append(self, item):
icon = Button(
# +
parent = inventory.item_parent,
model =
'quad',
texture = item,
# +
color = color.white,
# +
origin = (-.
5,.
5),
position = self.find_free_spot(),
z = -.
1,
)
name = item.replace(
'_',
' ').title()
# +
icon.tooltip = Tooltip(name)
# +
icon.tooltip.background.color = color.color(
0,
0,
0,.
8)
# +
# text, size 1
# size 2, bold
8 Drag n' drop
# size 1, normal
We can
't move the items! That's
not fun.
However, that's easy to change. Just spawn a Draggable instead of Button.
Draggable inherits
from Button, so the tooltips will still work!
# code, size .8
def append(self, item):
icon = Draggable(
# +
parent = inventory.item_parent,
model =
'quad',
texture = item,
color = color.white,
origin = (-.
5,.
5),
position = self.find_free_spot(),
z = -.
1,
)
name = item.replace(
'_',
' ').title()
icon.tooltip = Tooltip(name)
icon.tooltip.background.color = color.color(
0,
0,
0,.
8)
# text, size 1
# size 2, bold
9 Snap to grid on_drop
# size 1, normal
The items can be moved now, but they don't follow the grid.
Let's round the position when we drop it.
Draggable's will automatically call on_drag() and on_drop()
if has them.
round the position on drop
# code, size .8
def append(self, item):
icon = Draggable(
parent = inventory.item_parent,
model =
'quad',
texture = item,
color = color.white,
origin = (-.
5,.
5),
position = self.find_free_spot(),
z = -.
1,
)
name = item.replace(
'_',
' ').title()
icon.tooltip = Tooltip(name)
icon.tooltip.background.color = color.color(
0,
0,
0,.
8)
def drop():
# +
icon.x = int(icon.x)
# +
icon.y = int(icon.y)
# +
icon.drop = drop
# +
# text, size 1
# size 2, bold
10 Swap items
# size 1, normal
Add a drag function to remember the start position as org_pos.
# code, size .8
def drag():
# +
icon.org_pos = (icon.x, icon.y)
# +
def drop():
icon.x = int(icon.x)
icon.y = int(icon.y)
'''
if the spot is taken, swap positions
'''
for c in self.children:
# +
if c == icon:
# +
continue
# +
if c.x == icon.x and c.y == icon.y:
# +
print(
'swap positions')
# +
c.position = icon.org_pos
# +
icon.drag = drag
# +
icon.drop = drop
# text, size 1
# size 2, bold
11 Stay inside the inventory, please
# size 1, normal
We shouldn't be able to drop the items outside of the inventory.
# code, size .8
def drop():
icon.x = int(icon.x)
icon.y = int(icon.y)
'''
if outside, return to original position
'''
# +
if icon.x <
0 or icon.x >=
1 or icon.y >
0 or icon.y <= -
1:
# +
icon.position = (icon.org_pos)
# +
return
# +
'''
if the spot is taken, swap positions
'''
for c in self.children:
if c == icon:
continue
if c.x == icon.x and c.y == icon.y:
print(
'swap positions')
c.position = icon.org_pos
icon.drop = drop
# text, size 1
# size 2, bold
12 Bugfix: Make the dragged items render on top
# size 1, normal
All the items are at the same depth, so it hard to say how they will overlap.
It feels natural that the item we're currently dragging stays on top,
so we'll move it back a bit when we drag it and forward when we drop it.
# code, size .8
def drag():
icon.org_pos = (icon.x, icon.y)
icon.z -= .
01 # ensure the dragged item overlaps the rest # +
def drop():
icon.x = int(icon.x)
icon.y = int(icon.y)
icon.z += .01 # +
'''if outside, return to original position'''
if icon.x < 0 or icon.x >= 1 or icon.y > 0 or icon.y <= -1:
icon.position = (icon.org_pos)
return
'''if the spot is taken, swap positions'''
for c in self.children:
if c == icon:
continue
if c.x == icon.x and c.y == icon.y:
print('swap positions')
c.position = icon.org_pos
icon.drag = drag
icon.drop = drop
# text, size 1


Hi! I'm Michael, and I draw pictures with tiny squares.
I've been playing Minecraft since 2012, and since the start I've loved making textures for the game. I loved being able to see my own drawings making up the world around me, and making sweeping changes with relatively low effort. Even when I got burnt out on the game, I would still make textures and models for fun. Minecraft was my first real exposure to pixel art, and it encouraged me to experiment with new forms and styles of digital drawing. Even though I don't play it as much as I used to, Minecraft will always have a special place in my heart, and be a core part of my childhood.
If you like what I've done here, whether in the Pack Builder or Other Resource packs, please consider buying me a Boba through the PayPal link below.


Creates a data method in a JUnit 4 Parameterized test class.
Predefined variables take the following values:
${NAME}
Name of the created method
${BODY}
Generated method body


Hi all,
I've just got OEM bundle, emonTx V3, RFM12Pi V2 (attached to RPi) and got software installed.
However, I notice I get corrupted data from the RFM12Pi. Known problem?
? 10 251 255 0 0 0 0 0 0 15 1?0 0 0
10 252 255 0 0 0 0 0 0 179 99 0 0
10 252 255 0 0?0 0 0 0 133 9? 0 0
10 251 255 0 0 0 0 0 0 74 99 0 0
10 254 255 0 0 0 0 0 0 80 99 0 ?
1? 252 255 0 0 ? 0 0 0 10 99 0 0
1? 252 25? 0 0 0 0 0 0 31 ?9 0 0
10 252 255 0 0 0 0 0 0 33 99 0 0
10 252 255 0 0 0 0 0 0 22 99 0 0
10 253 255 0 0 0 0?0 0 20 99 0?0
10 252 255 0 0 0 0 0 0 22 99 0 0
10 252 255 0 0 0 0 0 0 4 9? 0 0
10 251 255 0 0 0 0 0 0 4 99 0 0
10 252 255 0?0 0 0 0 0 253 98 0 0
10 253 255 0 0 0 0 0 0 230 99 0 0
10 251 255 ??0 0 0?0 0 2 ?00 0 0
Thanks.
Re: RFM12Pi V3 corrupted data [SOLVED]
I'm an experienced engineer, but new to openenergy monitor. What I can tell you is that I bought a RFM12Pi V2 a week ago, Built the SD card (IPE locked file system running Python) following instructions on this site. It receives data from RFM12 on the openenergy Tx Shield fine, So I don't think this is a known or common problem, It is frustrating if you get a problem like this, as there are so many variables.
Make sure you've edited the Python config script and the Arduino sketch correctly, so that the frequency the software sets matches the hardware of both your RFM modules, and try putting the transmitter and receiver .so that you can eliminate weak signal as the cause.
Re: RFM12Pi V3 corrupted data [SOLVED]
I am an experienced engineer, too. RF protocol sends bytes over the wire and not strings (bytes converted into strings). The output clearly shows that the problem is communication problem between RFM12 board and RPi.
If I do "t" command in minicom I get:
A?ailable commands:
?23 x ? ? Tog?le c?nfiguration ?hange protection, 1?Unlocked
<nn> i - set node ID (standard node ids are 1..26)
<n? b - set MHz?band (4 = 433, 8 = 868, ? = 915)
<nnn> g - ?et network?group (RFM12 o?ly ?llows 212, 0 = any)
<n> c? - set collect ?ode (advan?ed, ?ormally 0)
.?.,<nn> a - se??data packe???? node <??>, ?ith ?ck
?..,<nn> s - send da?a packet to node <nn>, no ack
?<n> l ?- turn?activ?ty LED on?DIG8 on or off
Current configura?ion:
79?i15 g?10 @ 86??MHz L??뺠1
As you see, no RF communication data, just help printed from RFM12Pi board.
I've desoldered low quality connector on RFM board and replaced with a decent one. Less errors, but still. Faulty RFM board? Frequency mismatch, RPi UART problem... I do not know :/
Re: RFM12Pi V3 corrupted data [SOLVED]
What software is installed, ready made image, apt-get package or did you follow a guide if so which one ?
Have you edited both the /boot/cmdline.txt to confirm it does not contain "console=ttyAMA0,115200kgdboc=ttyAMA0,115200" and the /etc/inittab to confirm this line (usually the last line) "# T0:23:respawn:/sbin/getty-LttyAMA0115200vt100" has the hash to commented it out ?
Is there anything else installed accessing the serial uart?
Paul
Re: RFM12Pi V3 corrupted data [SOLVED]
apt-get installation. I've removed both lines.
Weird character come only when RMF12Pi is emitting data, therefore I conclude it's a communication problem.
Re: RFM12Pi V3 corrupted data [SOLVED]
Yes.it is a bit odd. The RFM2Pi are normally very reliable and this issue is not something I've come accross before.
Since the "A?ailable commands:" are also corrupt it looks like a serial/uart issue, is there any other software running on the RPi that maybe trying to use the uart and clashing?. If there isn't then it may well be a hardware issue with the serial port, either with the Pi or the RFM2Pi. Not sure how you would prove either without substitution of one or the other.
You could try connecting the v3 directly to the RPi uart like this http://wiki.openenergymonitor.org/index.php?title=EmonTx_V3#Wired_Connectivity to eliminate an issue with the RPi.
Paul
Re: RFM12Pi V3 corrupted data [SOLVED]
I'll try that and I'll let you know...
Re: RFM12Pi V3 corrupted data [SOLVED]
Direct RPi <-> emonTX V3 communication works flawlessly. I've tried 2 different firmwares and they both work OK. But when I connect RFM12Pi I get corrupted chars over the serial.
Re: RFM12Pi V3 corrupted data [SOLVED]
Well I think that certainly suggests the RFM2Pi could be the cause.
Normally I would suggest trying to update the RFM2Pi firmware or reinstalling the firmware might be a better term as I would reinstall even if there wasn't a later revision, In this case, since the firmware is updated over serial, I think it would be wise to email the guys at the shop and include a link to this forum thread before considering a firmware update.
<EMAIL_ADDRESS>Re: RFM12Pi V3 corrupted data [SOLVED]
Message received. We'll send out a replacement. Sounds like there could be some sort of fault. Strange, I've not experienced this before. I'll update this thread when I receive back the faulty unit and have a chance to debug myself.
Thanks a lot Paul for helping to debug.
Re: RFM12Pi V3 corrupted data [SOLVED]
Thanks for excellent and instant response.
Re: RFM12Pi V3 corrupted data [SOLVED]
Today I received a new RFM12Pi. I've replaced the old one with the new one... and it works flawlessly. No corrupted data. Thanks.


Reset Password
Enter your account's email address and you will be sent a new password.
Email:
Invalid Email
Submit


--- layout: archive title: Zulip Chat Archive permalink: /stream/116395-maths/topic/units.20and.20is_unit.html ---
Are we happy with the design of units
and is_unit
?
structure units (α : Type u) [monoid α] := (val : α) (inv : α) (val_inv : val * inv = 1) (inv_val : inv * val = 1) def is_unit [monoid α] (a : α) : Prop := ∃u:units α, a = u
This was a bit of a surprise to me. A more common pattern would be to define is_unit
as a structure with three fields, and then units
as a dependent pair, an element and evidence that it was a unit.
I guess the current design has the (small?) advantage that we can put is_unit
in Prop
, rather than just show it's a subsingleton.
I guess the reasoning is: the type of units
must record the inverse, not only its existence, and is_unit
must be a Prop
. Under those two conditions, the resulting definitions are quite reasonable....
The only reasonable variation I can see is to make is_unit
a type that records the inverse (and is a subsingleton). With that version you could factor it the other way around, but if is_unit
is a prop then this approach is easier
I believe is_unit
came later, and it was needed for defining an ideal or something so it was necessary for it to be a prop
At the same time, e.g., is_iso
records the inverse. If we need Prop
, we can always use nonempty (is_unit x)
.
I would argue that is_iso
is not following the naming convention then, although maybe it's fine if the propositional version is not useful in category theory
We should come up with a naming convention for these "witnesses in Type" for existential predicates, but I'm at a loss as to what it should be. unit_of
? inverse
?
Last updated: Apr 24 2020 at 19:02 UTC


The week of December 6th we had a web development 101 training class in Davis CA. It was fun. Come to the next class and see how cool we are


{%extends 'base.html'%} {% block content %}
These are some of the sports offered during fun olympics.
This is our banner for funolympics
Above competition, we aim to have fun.
Located at: {{facilitydisplay.facilityLocation}}
{{n.postDate}}
{{n.description}}


Lorem Ipsum is simply dummy text of the printing and typesetting industry.
 Pariatur perferendis sapiente aut dolores laborum, in adipisci necessitatibus. Ducimus praesentium soluta repudiandae harum nisi distinctio possimus veniam aliquam dolor, delectus voluptatem!Lorem ipsum dolor sit amet, consectetur adipisicing elit. Debitis, similique facere. Rem aliquam consequuntur quasi aspernatur laboriosam nulla, similique minus labore, odit ut aperiam, omnis incidunt quaerat sint adipisci. Soluta.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever sinc
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever sinc
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's standard dummy text